lunes, 14 de mayo de 2012
Historia de una ciudad
Imagina que vives en un pequeño pueblo donde cada uno vive su vida, junto a los demás, pero independientes.
Un día, os dais cuenta de que hay cosas que se harían de forma mucho más eficiente si colaboráis. Por ejemplo, pensáis que para limpiar las calles lo mejor es que todo lo haga solo una persona en vez de que cada uno limpie su trozo. O que puede haber alguien que se encargue de cuidar a los niños de todos por las mañanas, en vez de que cada familia tenga que dedicar una persona a cuidar a un sólo niño. Así que empezáis a organizaros, y como vais a tener que pagar a la gente para que haga estas cosas, decidís poner bote.
Pero en vez de tener que organizarlo todo entre todos, también llegáis a la conclusión de que lo mejor es contratar a alguien para que se dedique a eso. Así que elegís a una persona, le dais el bote todos los meses, y confiáis en que guarde vuestro dinero, pague a los demás y organice todas esas tareas comunes. Por supuesto que también cobrará un sueldo por su trabajo.
Resumiendo, que cada uno de vosotros, a final de mes, metéis una parte de vuestro sueldo en un sobre y lo juntáis con lo de los demás, para pagar estos servicios comunes que habéis organizado. Le dáis todo el dinero al gestor, Pepe. Él se queda con una parte, y el resto lo reparte entre los demás trabajadores comunes. Pepe también es el encargado de la organización, que para eso cobra. Tiene que decidir qué tareas son más importantes, quién las puede hacer mejor, cómo ahorrar, cómo gastar el dinero común... Y todo empieza a funcionar mucho mejor.
Un tiempo más tarde, otro vecino se compra una caja fuerte que los demás no podéis comprar. Y consigue convenceros de que el mejor sitio para guardar vuestro dinero es una caja fuerte como la suya. Porque algún otro vecino puede decidir robaros, porque sea mala persona, porque no tenga para comer o cualquier otro motivo. Así que él se ofrece a guardaros el dinero si le pagáis un pequeño precio, y a todos los vecinos os parece bien.
Cada final de mes, coges tu sueldo, metes parte en un sobre que le llevas a Pepe, y el resto lo metes en otro sobre y se lo llevas a Juan, el de la caja fuerte, para que te lo guarde.
No pasa mucho tiempo hasta que Juan empieza a pensar que tener tanto dinero ahí guardado es un desperdicio, ya que podría invertirse para hacer algo útil. Otro vecino dice que a él le vendría muy bien ese dinero para mejorar sus huertos, y que después con los huertos nuevos ganará mucho dinero más, con lo que podrá devolver el dinero que se le prestó. ¡Qué idea tan buena! Pensáis. A partir de ese momento, Juan, con el dinero que os está guardando, se dedica a dar préstamos para luego recuperar el dinero con intereses. Todos salís ganando.
Cuando los préstamos se han generalizado, Pepe se da cuenta de que él también podría aprovecharse de ellos. Por ejemplo podría pedir un préstamo a Juan para arreglar las calles, de forma que todos os beneficiaríais y mejoraría la calidad de vida del pueblo. Y empieza a pedir préstamos.
Es decir, a final de cada mes, una parte de tu dinero se la das a Pepe, el resto a Juan, y Juan con el dinero de todos los vecinos concede préstamos a algunos de ellos, y también a Pepe. Además, Pepe y Juan cobran un sueldo del bote mensual, que no se nos olvide, y se están haciendo muy amigos.
Un día Pepe comprende que hacen falta más casas en el pueblo, y que hay que construír. Juan lo ve claro, tiene un amigo albañil que hace casas de maravilla. Así que Pepe le dice al amigo de Juan, que se llama Antonio, que se dedique a construír por el bien de los vecinos. Pero para poder construír casas Antonio necesita préstamos de Juan, que se los concede sin problemas. Antonio os vende las casas construidas a los vecinos a un precio superior al que a él le cuesta hacerlas, para poder cobrar su sueldo y pagar los préstamos.
A final de mes, le das una parte de tu dinero a Pepe, el resto a Juan. Juan le presta tu dinero a Pepe y a Antonio. Antonio os vende casas al doble de lo que cuesta hacerlas, y para pagarlas tenéis que pedir préstamos a Juan, que luego os cobra intereses cada vez más altos por prestaros vuestro propio dinero.
Llegados a este punto alguien podría pensar ¿y no se podría hacer todo esto de forma más sencilla? ¿de verdad es necesario todo esto para que podamos vivir en el pueblo? Pero realmente nadie se lo plantea, las cosas van bien y todos contentos.
Sin embargo, un día la gente empieza a pensar que conceder créditos así tan a la ligera puede ser peligroso, ya que algún vecino quizá no pueda pagarlo, y entonces... ¿qué pasará? Así que algunos vecinos empiezan a sentirse inseguros, y deciden que ya no confían en Juan para que les guarde el dinero. Juan, con menos dinero, deja de poder prestar a otros vecinos, que dejan de poder comprar casas. Antonio deja de vender pisos, así que deja de poder pagar sus préstamos a Juan.
Juan empieza a entender que puede haber perdido todo el dinero que los vecinos le dan para que guarde, ya que no tiene forma de recuperar lo prestado, así que se pone muy nervioso. Pepe, del que también se ha descubierto que se ha llevado dinero del bote durante mucho tiempo, y que se ha hecho muy amigo de Juan, se da cuenta que eso no puede pasar. Si Juan ha perdido el dinero, entonces todo se desmorona. Así que decide coger el dinero del bote y prestárselo a Juan para que pueda devolvérselo a los vecinos.
Por tanto, el dinero del bote mensual se utiliza para cubrir las pérdidas del resto de dinero de los vecinos que han ocurrido por culpa de Juan. Además se convence a los vecinos de que si no se le presta dinero del bote a Juan, éste habrá perdido todo el dinero del pueblo sin remedio. Juan con este nuevo préstamo intenta recuperar el dinero perdido. Pero resulta que dicho dinero ni siquiera existe, ya que ha prestado más dinero del que tenían realmente los vecinos, así que acaba perdiendo también este nuevo préstamo.
Es decir, que a final de mes, tú pones una parte de tu sueldo en un sobre y se lo das a Pepe, y el resto a Juan. Pepe coge el dinero que le has dado y se lo presta a Juan. Además Pepe deja de pagar los servicios comunes. Juan ha perdido todo el dinero, y el dinero que le presta Pepe se va a la basura. Mientras, todos los vecinos que no pueden devolver los préstamos a Juan se quedan sin sus casas, a pesar de que el dinero que les han prestado es el suyo propio. Antonio deja un montón de casas sin terminar, su dinero y él desaparecen, aunque le ha dado un parte a Pepe para que se mantenga callado.
Y así, llegados a este punto... ¿Cómo creéis que se sale del círculo vicioso? ¿Qué deberían hacer los vecinos? ¿Prestarle más dinero a Juan? ¿Dejar de pagar los servicios comunes? ¿Quitarles sus casas a los que no pueden pagar para que Juan intente vendérselas a otros vecinos, que a su vez tendrán que pedir préstamos al mismo Juan?
Y lo peor, es que muchos vecinos aún creen que sólo Pepe y Juan pueden sacarles de la crisis.
sábado, 21 de abril de 2012
Cómo crear una empresa de éxito en 4 pasos
Sólo para políticos
Paso 1.
Cree un servicio público con el dinero de los impuestos de millones de ciudadanos durante muchos años. Si no dispone de tanto tiempo, elija un servicio de los ya existentes. Cuantos más usuarios tenga el servicio, y más necesario sea, mucho mejor.
Paso 2.
Desde dentro de la dirección de dicho servicio, tome malas decisiones. Húndalo.
Paso 3.
Convenza a los ciudadanos de que dicho servicio no sirve para nada más que para tirar el dinero. Que es un servicio ruinoso, y que invertir más en él no sirve para nada. Es un servicio que da una mala atención a sus usuarios, y la gente que lo da son unos vagos y están demasiado bien pagados.
No se preocupe, si ha hecho bien el paso anterior, esto no le será difícil.
Paso 4.
En este punto los ciudadanos estarán convencidos de que por su propio bien y para solventar las cuentas del Estado, lo mejor que se puede hacer es privatizar el servicio.
Véndaselo a su mejor amigo. Si lo ha hecho bien hasta aquí, incluso será probable que salga reelegido en las próximas elecciones, ya que usted ha servido bien los intereses de sus compatriotas.
¡Bingo!
Su amigo, que ya era rico de antemano, tiene ahora mucho más dinero y dispone de una nueva empresa con millones de clientes, que además ha sido creada con el dinero de sus propios clientes.
Y no se preocupe, en el caso de que no salga reelegido, siempre tendrá garantizado un puesto en el consejo de administración de la empresa de su amigo.
Consejo final
En el caso de que sus adversarios políticos se le hayan adelantado y hayan privatizado el servicio antes que usted, nacionalícelo. Así podrá elegir si quiere controlarlo desde el propio gobierno, o si, pasados unos años, quiere volver a empezar con el proceso desde el paso 1 para hacerle un regalo a ese amigo especial.
Por 25 pesetas la respuesta, díganos ejemplos de empresas exitosas creadas de esta forma. Un, dos, tres, ¡responda otra vez!
viernes, 10 de febrero de 2012
Generación de certificados PKCS12 con OpenSSL
Va a hacer ahora un año que hice por última vez algún desarrollo en el que tuviera que utilizar certificados y firmas digitales. Recordándolo, siempre tuve la sensación de que había demasiada poca información disponible de cómo tratar con ellos en distintas plataformas, y siempre información muy atomizada y para casos concretos, nunca una guía extensa sobre las diferentes opciones para el desarrollo.
Voy a ver si durante una serie de posts consigo resumir algo de la información que aprendí entonces.
El formato de certificados de cliente más extendido es el PKCS12, básicamente porque es el que se utiliza en windows, que sigue siendo el sistema operativo de cliente más extendido. La forma de mover estos certificados suele ser mediante un fichero que tiene extensión pfx y está protegido por contraseña. Esta contraseña básicamente lo que hace es cifrar el contenido del fichero para que, si alguien nos lo roba, no pueda acceder a nuestro certificado.
Normalmente estos certificados de cliente los podemos obtener de entidades reconocidas, que nos los emiten para que podamos acreditar que somos quien decimos ser. Ahora bien, para el desarrollo de aplicaciones necesitamos tener certificados de prueba, que no necesariamente tienen que estar emitidos por una entidad de confianza, sino por nosotros mismos.
Para generar nuestros propios certificados disponemos de varias herramientas, pero voy a centrarme en una que está disponible tanto para Linux como para Windows, pero que en los sistemas Linux suele venir además instalada por defecto: OpenSSL.
Si vamos a generar muchos certificados y simular el comportamiento real de la aplicación, lo primero que tendríamos que hacer es generarnos nuestra propia CA (entidad certificadora). Para ello, podemos seguir las siguientes instrucciones
Estas instrucciones están sacadas del post http://www.flatmtn.com/article/setting-openssl-create-certificates, del blog Flat Mountain que no sé si está abandonado o no publica mucho, pero que tiene información útil como ésta y muy bien explicada. Una vez tenemos nuestras claves raíz creadas, podemos crear los certificados de clientes. Os pongo aquí las instrucciones de cómo hacerlo sacadas del mismo blog.
Una vez llegados a este punto, ya somos capaces de generar certificados para usuarios emitidos todos por la misma CA. De esta forma, más adelante podremos indicarle a nuestra aplicación que puede confiar en los certificados de usuario emitidos por dicha CA, algo muchas veces indispensable para el desarrollo de aplicaciones basadas en estas tecnologías.
Tengo intención de seguir con este tema en siguientes posts. En el próximo veremos cómo utilizar estos certificados para firmar información desde aplicaciones desarrolladas en C, utilizando también OpenSSL.
Voy a ver si durante una serie de posts consigo resumir algo de la información que aprendí entonces.
El formato de certificados de cliente más extendido es el PKCS12, básicamente porque es el que se utiliza en windows, que sigue siendo el sistema operativo de cliente más extendido. La forma de mover estos certificados suele ser mediante un fichero que tiene extensión pfx y está protegido por contraseña. Esta contraseña básicamente lo que hace es cifrar el contenido del fichero para que, si alguien nos lo roba, no pueda acceder a nuestro certificado.
Normalmente estos certificados de cliente los podemos obtener de entidades reconocidas, que nos los emiten para que podamos acreditar que somos quien decimos ser. Ahora bien, para el desarrollo de aplicaciones necesitamos tener certificados de prueba, que no necesariamente tienen que estar emitidos por una entidad de confianza, sino por nosotros mismos.
Para generar nuestros propios certificados disponemos de varias herramientas, pero voy a centrarme en una que está disponible tanto para Linux como para Windows, pero que en los sistemas Linux suele venir además instalada por defecto: OpenSSL.
Si vamos a generar muchos certificados y simular el comportamiento real de la aplicación, lo primero que tendríamos que hacer es generarnos nuestra propia CA (entidad certificadora). Para ello, podemos seguir las siguientes instrucciones
1) Create a directory
Let's call it sslcert:
mkdir sslcert
mkdir sslcert
Now protect that directory so only the user you are running as (and root) can access it:
chmod 0700 sslcert
chmod 0700 sslcert
Cd into the first directory and make two subdirectories. Let's call them certs and private.
cd sslcert
mkdir certs private
cd sslcert
mkdir certs private
Type:
echo '100001' >serial
touch certindex.txt
echo '100001' >serial
touch certindex.txt
Create a file using your ASCII text editor. We will call it openssl.cnf. Here are the basics needed for this exercise (edit as needed):
# # OpenSSL configuration file. # # Establish working directory. dir = . [ ca ] default_ca = CA_default [ CA_default ] serial = $dir/serial database = $dir/certindex.txt new_certs_dir = $dir/certs certificate = $dir/cacert.pem private_key = $dir/private/cakey.pem default_days = 365 default_md = md5 preserve = no email_in_dn = no nameopt = default_ca certopt = default_ca policy = policy_match [ policy_match ] countryName = match stateOrProvinceName = match organizationName = match organizationalUnitName = optional commonName = supplied emailAddress = optional [ req ] default_bits = 1024 # Size of keys default_keyfile = key.pem # name of generated keys default_md = md5 # message digest algorithm string_mask = nombstr # permitted characters distinguished_name = req_distinguished_name req_extensions = v3_req [ req_distinguished_name ] # Variable name Prompt string #------------------------- ---------------------------------- 0.organizationName = Organization Name (company) organizationalUnitName = Organizational Unit Name (department, division) emailAddress = Email Address emailAddress_max = 40 localityName = Locality Name (city, district) stateOrProvinceName = State or Province Name (full name) countryName = Country Name (2 letter code) countryName_min = 2 countryName_max = 2 commonName = Common Name (hostname, IP, or your name) commonName_max = 64 # Default values for the above, for consistency and less typing. # Variable name Value #------------------------ ------------------------------ 0.organizationName_default = My Company localityName_default = My Town stateOrProvinceName_default = State or Providence countryName_default = US [ v3_ca ] basicConstraints = CA:TRUE subjectKeyIdentifier = hash authorityKeyIdentifier = keyid:always,issuer:always [ v3_req ] basicConstraints = CA:FALSE subjectKeyIdentifier = hash
All other certificates you create will be based off of this. Because you are not a commercial certificate authority, software may complain when they use your certificates. However you can give people one of the files, the "public" one, that will be created and they can manually import it. From then on your certificates will load just like the commercial ones.
To create, while in the 'sslcert' directory, type:
openssl req -new -x509 -extensions v3_ca -keyout \
private/cakey.pem -out cacert.pem -days 365 -config ./openssl.cnf
openssl req -new -x509 -extensions v3_ca -keyout \
private/cakey.pem -out cacert.pem -days 365 -config ./openssl.cnf
Note the backslash (\) at the end of the first line. If your OS supports it, this is a way to type long command lines. Simply press after it and you will be prompted to continue typing. Otherwise, leave it out and continue typing.
Note the -days 365 option. For a root certificate you may want it to last longer than one year so that you do not have to reissue it so often. I set mine to 10 years.
You will be prompted for information and a password. Do not loose this password, make sure it is a secure one, and back up the two files that are created.
The two files that are created are cacert.pem, which is the one you can give to others for import in their browsers, and cakey.pem, which will be in the private directory.
6) Installing the root certificate for use
See your browser's help for how to do this. For IE, go to Tools, Options, Content tab, Certificates, Import and follow the steps. Note that we called our root certificate cacert.pem. Rename this file to cacert.crt as it is an X.509 certificate. To make it easy for people to install your root certificate, cacert.crt, place it on your web site with a URL to it. When they click on it in most modern browsers, they can choose to "Open" or "Install" and it will walk them through the install steps.
Note for Mozilla and Firefox/Thuderbird users: Mozilla apps do not use MS Windows' certificate storage. If you use Mozilla, you only need to install the certificate in the browser and it will be available to the email client. If you use Firefox and Thunderbird, or just one of the two, you will need to manually import the certificate with Thunderbird. To do this, right-click the link to the certificate and choose "Save As...". Then in "Manage Certificates", access is via "Advanced" in newer versions, click the Import button.
Estas instrucciones están sacadas del post http://www.flatmtn.com/article/setting-openssl-create-certificates, del blog Flat Mountain que no sé si está abandonado o no publica mucho, pero que tiene información útil como ésta y muy bien explicada. Una vez tenemos nuestras claves raíz creadas, podemos crear los certificados de clientes. Os pongo aquí las instrucciones de cómo hacerlo sacadas del mismo blog.
1) Setup and create root certificate
Note: If all you are going to be creating is certificates to sign files and/or emails, and have an old box around I highly recommend loading it up with Apache, PHP, OpenSSL. Install PHPki and use it to create and manage your certificates. However, make sure this computer is not accessible over the internet.
Assuming you have your root certificate created and you are in the 'sslcert' directory you can start creating certificates for each person in your company, or at least each one you want to be able to digitally sign drawings (or email or anything else certificates can be used for).
Type (all one line):
openssl req -new -nodes -out name-req.pem -keyout private/name-key.pem -days 365 -config ./openssl.cnf
openssl req -new -nodes -out name-req.pem -keyout private/name-key.pem -days 365 -config ./openssl.cnf
Note the number of days. For employee certificates I like to keep this fairly short, but a year may be too short. For a newly hired person you might want to do it for the length of their probation period and then reissue it for longer after that.
You will be prompted for information, much like when creating the root certificate. I put "Employee" for the Organizational Unit, make sure to use their correct internet email address for Email Address, and use their full name for Common Name.
Name Field | Explanation |
---|---|
Country Name | The two-letter ISO abbreviation for your country |
State or Province Name | The state or province where your organization is located. Can not be abbreviated. |
City or Locality | The city where your organization is located. |
Organization Name | The exact legal name of your organization. Do not abbreviate |
Organizational Unit | Optional for additional organization information. |
Common Name | The person's full name. |
Email address | The person's email address |
Once you are done with the input, two files will be created:
name-req.pem - the request
name-key.pem - the private key in the private directory
name-req.pem - the request
name-key.pem - the private key in the private directory
This will generate the certificate.
Type:
openssl ca -out name-cert.pem -days 365 -config ./openssl.cnf -infiles name-req.pem
openssl ca -out name-cert.pem -days 365 -config ./openssl.cnf -infiles name-req.pem
You will be prompted for the password used when creating the root certificate. Then you will be given a chance to review the information before signing. If anything is incorrect, now is the time to stop and redo things.
Two files are created:
name-cert.pem - which is the certificate
.pem - a copy of it in the certs directory.
name-cert.pem - which is the certificate
This file combines the person's public key, private key, and root certificate into one file.
Type (all one line):
openssl pkcs12 -export -in name-cert.pem -inkey private/name-key.pem -certfile cacert.pem -name "[friendly name]" -out name-cert.p12
openssl pkcs12 -export -in name-cert.pem -inkey private/name-key.pem -certfile cacert.pem -name "[friendly name]" -out name-cert.p12
[friendly name] can be what you want, but I use the person's full name (note: do not enclose any part of this with quotes, such as a nick name). You will be prompted for an "export password". This is what the user will use when they import the file and if they lose this file and need to export it from a storage "service" for use elsewhere. I let my people come over and type their own, since it is unchangeable once created.
Before you transfer them, note that the p12 format is binary and the pems are text. (This matters with FTP and a few other situations.) Also remember that the name-key.pem is the private key and should be guarded, whereas the name-cert.pem is the public certificate. While name-cert.p12 is encrypted with the password, it does contain the private key so I wouldn't leave it laying out for just anyone to get to.
The name-cert.p12 file is the one to give the person. They will need to know the export password used when creating the file. You can also give them their name-cert.pem and name-key.pem if you want. However, stress that if the name-cert.p12 file or the name-key.pem is compromised, ie lost or misplaced, that they must tell you immediately. Then you must revoke their existing one and issue a new one.
How the users import them depends on the application.
Tengo intención de seguir con este tema en siguientes posts. En el próximo veremos cómo utilizar estos certificados para firmar información desde aplicaciones desarrolladas en C, utilizando también OpenSSL.
Suscribirse a:
Entradas (Atom)