• Require HIGH or MEDIUM level SSL/TLS encryption at the transport (TCP) layer
• Browser must use SSLv3 or TLSv1, not SSLv2
• Require username/password authentication for some subdirectories
• Be a mini-CA (Certificate Authority)
• Use a non-standard port to keep most of the port-scanning riffraff away

The key to this whole system is the SSL/TLS protocol. SSL stands for Secure Sockets Layer, and it was developed by Netscape to enable secure transactions over the Web. It operates between the TCP layer and the HTTP application layer. TLSv1 is the IETF standard implementation, based on SSLv3. TLS stands for Transport Layer Security.

Assumptions

First and foremost, this document assumes that you are using some flavor of Linux, Apache 2.0.x and that you have OpenSSL installed. Other assumptions:

• This will be used over the Internet
• Your DNS configuration is correct (hostname=FQDN, PTR records O.K., etc.)
• Your firewall is setup to allow connections on the chosen https:// port
• You have a second machine with a modern web browser for testing purposes
• In these examples, my FQDN and hostname is: mycompany.com

Step 1: Setup your own CA (Certificate Authority)

In order to run a secure (SSL/TLS encrypted) web server, you have to have a private key and a certificate for the server. For a commercial web site, you will probably want to purchase a certificate signed by a well-known root CA. For Intranet or special-purpose uses like this, you can be your own CA. This is done with the OpenSSL tools.

Here, we will make a private CA key and a private CA X.509 certificate. We will also make a directory for the certs and keys:

[root]# mkdir /root/CA
[root]# chmod 0770 /root/CA
[root]# cd /root/CA

[root]# openssl genrsa -des3 -out my-ca.key 2048
Generating RSA private key, 2048 bit long modulus
.....................................................+++
...................................................+++
e is 65537 (0x10001)
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:

[root]# openssl req -new -x509 -days 3650 -key my-ca.key -out my-ca.crt
Using configuration from /usr/share/ssl/openssl.cnf
Enter PEM pass phrase:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []:LK
State or Province Name (full name) []:Western
Locality Name (eg, city) []:Colombo
Organization Name (eg, company) [My Company Ltd]:MyCompany.Com
Organizational Unit Name (eg, section) []:Certificate Authority
Common Name (eg, your name or your server's hostname) []:mycompany.com CA
Email Address []:user@mycompany.com

[root]# openssl x509 -in my-ca.crt -text -noout

Notes: The first OpenSSL command makes the key. The second command makes the X.509 certificate with a 10-year lifetime. The third command lets you view the completed certificate. Make sure that you keep the password in a safe place, you will need this every time you sign another certificate! You will probably also want to make backups of the cert and key and lock them in a safe place.

Step 2: Make a key and a certificate for the web server:

Now, we have to make an X.509 certificate and corresponding private key for the web server. Rather than creating a certificate directly, we will create a key and a certificate request, then "sign" the certificate request with the CA key we made in Step 1. You can make keys for multiple web servers this way. One thing to note is that SSL/TLS private keys for web servers need to be either 512 or 1024 bits. Any other key size may be incompatible with certain browsers.

[root]# openssl genrsa -des3 -out server.key 1024
Generating RSA private key, 1024 bit long modulus
....++++++
.++++++
e is 65537 (0x10001)
Enter PEM pass phrase:
Verifying password - Enter PEM pass phrase:

[root]# openssl req -new -key server.key -out server.csr
Using configuration from /usr/share/ssl/openssl.cnf
Enter PEM pass phrase:
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) []:LK
State or Province Name (full name) []:Western
Locality Name (eg, city) []:Colombo
Organization Name (eg, company) [My Company Ltd]:mycompany.Com
Organizational Unit Name (eg, section) []:TechStaff
Common Name (eg, your name or your server's hostname) []:mycompany.com <=== This must be the real FQDN of your server!!!
Email Address []:user@mycompany.com

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

# openssl x509 -req -in server.csr -out server.crt -sha1 -CA my-ca.crt -CAkey my-ca.key -CAcreateserial -days 3650
Signature ok
subject=/C=LK/ST=Western/L=Colombo/O=mycompany.Com/OU=TechStaff/CN=mycompany.com/Email=user@mycompany.com
Getting CA Private Key
Enter PEM pass phrase:

[root]# openssl x509 -in server.crt -text -noout

Make sure that your server name is the same as the FQDN that your clients will use when connecting to your site. Also, let's get in the habit of protecting our keys with appropriate permissions:

[root]# chmod 0400 *.key

Now, we need to move the new keys and certs into the proper directories in the /etc/apache2 hierarchy:

[root]# cp server.crt /etc/apache2/ssl.crt
[root]# cp server.key /etc/apache2/ssl.key
[root]# cp my-ca.crt /etc/apache2/ssl.crt

Step 3: Create directories and files for the secure web service

I do not want the secure branch of my webserver directory tree to be part of my "insecure" branch that serves unencrypted files. My normal web root directory is /var/www/ . The document root for the secure web server will be located at /var/www/SSL.

[root]# mkdir /var/www/SSL
[root]# chmod 0775 /var/www/SSL
[root]# cd /var/www/SSL
[root]# mkdir Passneeded

For testing purposes, create a simple HTML file in /var/www/SSL to print "Apache rocks with SSL" :)

Step 4: Configure the Apache web server

Create a file, let's say https.mycompany.com in /etc/apache2/sites-enabled/ to define your HTTPS virtualhost and include the following lines.

NameVirtualHost mycompany.com:443
<VirtualHost mycompany.com:443>

DocumentRoot "/var/www/SSL"

# Note that the FQDN and server hostname must go here - clients will not be able to connect, otherwise!
ServerName mars.vanemery.com:443
ServerAdmin webmaster@vanemery.com

# Here, I am allowing only "high" and "medium" security key lengths.
SSLCipherSuite HIGH:MEDIUM

# Here I am allowing SSLv3 and TLSv1, I am NOT allowing the old SSLv2.
SSLProtocol all -SSLv2

#   Server Certificate:
SSLCertificateFile /etc/apache2/ssl.crt/server.crt

#   Server Private Key:
SSLCertificateKeyFile /etc/apache2/ssl.key/server.key

#   Server Certificate Chain:
SSLCertificateChainFile /etc/apache2/ssl.crt/my-ca.crt

#   Certificate Authority (CA):
SSLCACertificateFile /etc/apache2/ssl.crt/my-ca.crt

# This is needed so that you can use auto-indexing for some directories in the
# /var/www/SSL directory branch.  This can be handy if you would like to have
# a list of sensitive files for people to download.
<Directory "/var/www/SSL">
        Options Indexes
        AllowOverride None
        Allow from from all
        Order allow,deny
</Directory>

Also you have to tell Apache, for all HTTPS requests use the port 443. For that append the following lines to /etc/apache2/ports.conf

<IfModule mod_ssl.c>
    Listen "443"
</IfModule>

Step 5: Start the web server and test

Run the following commands to start the the Apache web server:

[root]# /etc/init.d/apache2 start
Starting web server: apache2.
Server mycompany.com:443 (RSA)
Enter pass phrase:

Note that you will have to enter the password for your server key in order to start the server. You will also have to do this during boot if you have httpd configured to start automatically.

Make sure that the web server is now listening on the SSL/TLS port, TCP port 443:

[root]# netstat -tna
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:443             0.0.0.0:*               LISTEN

In order to test that your SSL/TLS web server is running, you will now need to connect to it with a browser. The URL you use should be https://mycompany.com. You will probably get a warning prompt about the Certificate Authority (CA) being unknown. You can view the certificate properties, which will look familiar because you created the cert yourself. You can save the cert in your browser, or import the my-ca.crt file into your browser as a new CA. How you do this will depend on which browser you are using.

Step 6: Require simple username/password auth for one of the directories:

We want to require a valid username and password for the /var/www/SSL/Passneeded directory. The username and password will be encrypted in transit as part of the TCP stream. We will need to setup the access control directives, as well as use the htpasswd command to add the username/password pairs.

[root]# htpasswd -c -m /etc/apache2/.htpasswd test_user1
New password:
Re-type new password:
Adding password for user test_user1
[root]# htpasswd -m /etc/apache2/.htpasswd test_user2
New password:
Re-type new password:
Adding password for user test_user2

[root]# chown apache.root /etc/apache2/.htpasswd
[root]# chmod 0460 /etc/apache2/.htpasswd

Now, we need to tell Apache to require a username/password to access the Passneeded directory. Here is what we will add to /etc/apache2/sites-enabled/https.mycompany.com file:

<Directory "/var/www/SSL/Passneeded">
	AuthType Basic
	AuthName "Username and Password Required"
	AuthUserFile /etc/apache2/.htpasswd
	Require valid-user
</Directory>

Now, restart the webserver with /etc/init.d/apache2 restart. When you try to access the Passneeded directory from a web browser, you should be prompted for a username and password. If you enter incorrect information, you should be denied access.

Step 7: Change the TCP port that Apache SSL/TLS listens on:

Since this is a private, special-purpose secure web server, you may want to change the TCP port from 443 to something else. This will make it just a little more difficult for crackers to locate via automated network scans. For this excercise, we will change the port to TCP 444 by editing the ports.conf configuration file and /etc/apache2/sites-enabled/https.mycompany.com. Make the following changes to the ports.conf:

<IfModule mod_ssl.c>
    Listen "444"
</IfModule>

And make the following changes in /etc/apache2/sites-enabled/https.mycompany.com:

NameVirtualHost mycompany.com:444
<VirtualHost mycompany.com:444>

Now, restart Apache and look at the listening ports:

[root]# /etc/init.d/apache2 restart

[root]# netstat -tna
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address           Foreign Address         State
tcp        0      0 0.0.0.0:80              0.0.0.0:*               LISTEN
tcp        0      0 0.0.0.0:444             0.0.0.0:*               LISTEN

Now, you should be able to connect to the server with this URL:

https://mycompany.com:444

Web Server Key Password:

You have probably noticed by now that every time you restart Apache or boot your server, you are forced to enter the password for the server key. This is a security measure, but it can be inconvenient. If you would like to make an insecure server key that will allow Apache to start automatically at boot time, then there is a way to do this. The choice is yours...

Here is how you do it:

[root]# cd /etc/apache2/ssl.key
[root]# cp server.key server.key.orig

[root]# openssl rsa -in server.key.orig -out server.key

[root]# chmod 0400 server*

Now, you should be able to restart Apache or boot your server without having to input the password. This may also be a very good time to copy all the keys and certificates that you made to floppy or CD. You can imagine what a pain it would be if you lost all of your keys and certs due to a disk failure. You may even want to make paper copies of the PEM encoded certificates and keys, which use ASCII text. Lock them in a secure place, along with any passwords.

Conclusion/Final Comments

As you can see, setting up a secure web server for some specific function is not that difficult. All the tools are included with a standard GNU/Linux distribution. OpenSSL is a fantastic Open Source toolkit that can be used in a number of applications. For example, you can use it to run files through different hashing functions, handle S/MIME encrypted mail, or encrypt & decrypt files.

In order to use Apache as a high-volume e-commerce server with SSL/TLS, you will probably need to do more configuration and hardware tuning. You may need to buy and configure a hardware crypto accelerator card. You will almost certainly want to purchase a "real" server certificate signed by Entrust, Thawte, or one of the other root-level CAs.

In any event, you now have a good feel for all the pieces, parts, and protocols that make it work!

Resources

• Apache 2.0 Documentation
• mod_ssl home page
• OpenSSL home page
• IETF TLS Charter
• The following man pages:
  • man openssl
  • man genrsa
  • man req
  • man x509
  • man pkcs12
  • man htpasswd

Tempo fa scrissi un articolo che parlava del  sistema operativo Ubuntu (Linux), ricordate? . Si metteva in luce la necessità, per noi informatici, di venire a conoscenza di quelle che sono le differenze tra Windows e Linux.  Si cercava di dare un significato ai tanti luoghi comuni e frasi fatte espresse dalla maggior parte degli utenti, del tipo : "Ubuntu e meglio di Windows" , "Ubuntu è più stabile" , "Windows si blocca sempre”, ecc..  Si era detto in quell'articolo che avrei aperto uno spazio in questo blog appunto per parlare di informatica, iniziando appunto dal nostro dilemma : E' meglio WINDOWS o LINUX?

Bene io e il mio gruppo di colleghi ci siamo posti questa domanda e siamo arrivati a delle conclusioni.

Non è stato un lavoro per niente facile. Il lavoro vero e proprio di test sui due sistemi operativi è stato preceduto da un'approfondito studio teorico che marchasse le principali caratteristiche di ciascun sistema. Naturalmente abbiamo tenuto sempre in considerazione ed approfondito quelli che sono i concetti di base che fanno parte della conoscenza del funzionamento di un sistema operativo tipo:  Kernel, scheduling di processi e thread, meccanismi di interrupt, gestione della memoria e studio dei sistemi multi processore SMP.

Ovviamente affermare che un sistema operativo è meglio di un altro, significa rendersi un po' conto di come tale sistema riesca a gestire ed ottimizzare i suoi processi in esecuzione sfruttando al massimo e al meglio le proprie risorse e conseguentemente riducendo notevolemente i tempi di esecuzione degli stessi. Ci si rende conto che il fine ultimo di un ottimale utilizzo delle risorse riguarda  una minore attesa da parte di un qualsiasi utente che magari si trova davanti ad un monitor e che deve attendere del tempo per avere a sua disposizione la macchina prima che la stessa completi di eseguire un programma. Quindi si capisce che se il sistema operativo è lento l'utente vedrà la macchina lenta o indisponibile. E' per questo che spesso siamo  indotti ad affemare che windows è meglio di linux o viceversa.

Per verificare effettivamente le prestazioni dei sistemi operativi analizzati, abbiamo pensato di eseguire dei test di benchmark per poter confrontare in termini non solo teorici i due sistemi. Questi test ci hanno, infatti, permesso di confrontare i tempi di esecuzione di varie applicazioni. I tempi osservati sono stati raccolti, analizzati e studiati per poterne trarre delle conclusioni finali per quel che riguarda le prestazioni di scheduling, relative ai due sistemi nell’esecuzione di processi multi-thread su un’architettura multi processore. La scelta dei programmi utilizzati per il test è ricaduta su quelle applicazioni maggiormente utilizzate in un ambiente desktop/workstation, e che ci desse, inoltre, la possibilità di eseguire lo stesso software su entrambi i sistemi operativi. Per eseguire questi test abbiamo ritenuto opportuno utilizzare una macchina vergine, con nessun sistema preinstallato, in modo da poter effettuare i test su un sistema operativo che non avesse applicazioni installate se non i driver delle periferiche. Il vantaggio di questo approccio è che, in questo modo, non essendo presenti applicazioni esterne al sistema stesso, eccetto gli applicativi di benchmark, si sono ridotti al minimo i processi/threads in esecuzione sulla macchina.

Si è proceduto secondo i seguenti punti:

- Formattazione della macchina

- Installazione di Windows XP PRO-SP2 (esclusi aggiornamenti)

- Installazione Ubuntu 8.04 e ricompilazione del Kernel ottimizzato per un sistema dual core

- Installazione e configurazione dei software

- Creazione degli script di benchmark

- Esecuzione dei test e raccolta dei risultati

- Analisi ed interpretazione dei dati raccolti.

I test sono stai effettuati sull'esecuzione dei seguanti applicativi: Mencoder, Lame, FAAC, Rar, OpenSSL, Blender.

Ecco a voi i risultati dei nostri test:

LAME, codifica audio.

Applicazione multithread nativa. Con un solo thread l'applicazione utilizza appieno un solo core. Con 2 thread si nota un dimezzamento dei tempi di esecuzione e pieno utilizzo dei due core. Con 4 thread Linux risente molto dell'utilizzo dei context switch

FAAC, codifica audio.

Configurazione multiprocesso, single thread. Nel caso di quattro processi di codifica contemporanei è interessante sottolineare come, mentre con linux i processi di codifica ottengono tempi di completamento pressoché identici all’interno della singola prova, con windows invece si possono notare tempi di completamento dei singoli processi molto differenti tra loro. Linux in questo conferma ulteriormente in questo test una migliore esecuzione parallela dei processi.

RAR

Differentemente dai test precedenti si nota che con due processi concorrenti il tempo registrato non è stato direttamente proporzionale al caso di un solo processo, ma superiore del 30%. Con 2 processi contemposanei la richiesta di risorse di calcolo veniva ad essere superiore a quella disponibile, causando un umento dei context switch e della prelazione tra processi.

Rendering video, BLENDER:

Blender è un'applicazione multithread. Si nota una riduzione notevole dei tempi di completamento sfruttando l'utilizzo di più thread. Con 8 thread le prestazioni migliore ulteriormente rispetto al primo caso. Si nota che Windows ha una risposta migliore. Il motivo è imputabile all'utilizzo dei driver video, proprietari in Windows e open source in Linux.

Crittografia, OPENSSL- DES3

Il test di crittografia evidenzia una migliore prestazione del file system EXT3 di Linux. L'NTFS di Windows subisce un calo di prestazioni proporzionale alla quantità di dati scritti fino a raggiungere una perdita del 41 % rispetto a EXT3 di Linux.

Crittografia, OPENSSL, MD5:

A causa della natura dell'applicazione, CPU intensive e diskless, si nota una riduzione dei tempi di completamento tra le prove eseguite in successione.

Conclusioni. Beh analizzando i risultati si nota che Windows mostra una migliore gestione delle applicazioni multithread come MPlayer e Blender.

Linux mostra invece un'ottimizzazione migliore dello scheduling per applicazioni CPU intensive ed una miglior gestione della cache per il riutilizzo delle istruzioni.

Per Windows si è notato un effettivo aumento di priorità data alle finestre in primo piano.

Per Linux si è notata una notevole stabilità dei tempi di completamento tra le singole prove. GLi altri processi nel sistema interferiscono in maniera non rilevante.

C'è da sottolineare però il fatto che, in generale, l'attenzione non è ricaduta tanto su quale dei due sistemi sia il "migliore" ma su come essi si distinguono nell'affrontare i problemi relativi alla gestione di applicativi Multi-thread e su architetture Multi-Core.

COMPARAZIONE DEI TEST:

RISULTATO FINALE: WINDOWS 10 - LINUX 13

Che ne dite?  E' come vi aspettavate?

ps. Tutto il lavoro di studio e di test è stato realizzato da me Daniele (guana), Oscar, Lorenzo e Gianluca.

Ci sentiamo al prossimo articolo.

ciao,

guana.

The bottom line is: Debian is far more secure than RHEL and Fedora, not due to technical reasons but for their development model. When Debian's openssl was compromised, they immediately issued a warning, told their users what to do, whilst Red Hat and Fedora were obscure, pointless and corporate-minded.

Dude, you are forgetting that it's entirely possible that the Debian's openssl security bug could have been the patient zero, and actual compromise of Red Hat's server could have been happened starting from a stolen passkey. Also, you are forgetting that, being Red Hat a corporate with some billions cash (of course, they have so much money because it's plenty of stupid people like me that pay them for their services) they were forced to work closely with law enforcement agencies such an intrusion could occur, and when FBI reaches the crime scene they are not primarily interested in sending an e-mail message on the mailing lists to tell them "ehy, we are here to save the day!".

Not so long ago, implementing SSL was so expensive compute-wise we had to deploy special cryptographic accelerator cards either on our load-balancers or on our edge servers.  One type of card we had was capable of 200 RSA signs/second, but cost ~$4000.00 each.  Theoretically we could stuff three of these cards into a web server,  achieving 600 signs/sec for $12000 (plus whatever the server costs.)

Fast forward 2008.   I recently evaluated a "low-end" Dell Poweredge SC1435 1U rackserver with a single dual-core 2.6GHz Opteron.  After installing FreeBSD/amd64 and recompiling OpenSSL from sources, running "speed rsa1024" computed 2000+ signs/sec per core, totalling 4100 RSA signs/sec.  Plus the SC1435 has an open socket for a second dual-core Opteron.

Not bad for a machine we bought for less than $800 on eBay.  Needless to say we have no performance concerns deploying our application with SSL enabled.  Thanks Mr. Moore.

Los administradores que controlan sus sistemas a través de SSH se suelen autenticar a través de su clave privada (el servidor de SSH almacena la pública correspondiente). Esta es una alternativa a la autenticación a través de la clásica contraseña simétrica. Si la pareja de claves ha sido generada con el OpenSSL vulnerable, se puede hacer un ataque de fuerza bruta sobre un espacio de claves muy pequeño, algo que tarda unos 20 minutos con un ordenador de hoy día. Los que hayan protegido el uso de las claves con contraseña, están en principio a salvo.

Aunque el US-CERT no habla de este problema en concreto, probablemente es el que está siendo aprovechado para llevar a cabo estos ataques durante estos días. Los atacantes están intentando acceder a servidores con SSH activo, protegido por criptografía pública y claves privadas vulnerables. Con esto consiguen acceso de forma fácil al sistema. Si el kernel no está actualizado, utilizan algún exploit para conseguir acceso local como root (existen decenas) y una vez dentro, instalan el rootkit Phalanx2 que les permite (entre otras cosas) obtener otras claves SSH para acceder a otros sistemas.

En el apartado de más información se ofrece información sobre cómo detectar el rootkit.

Como advertíamos en mayo, el problema criptográfico del paquete OpenSSL de Debian traerá de cabeza a los administradores durante mucho tiempo. Fueron casi dos años de generación de claves vulnerables en cientos de miles de máquinas, y pasará mucho tiempo hasta que todos los administradores parcheen sus sistemas y sobre todo, vuelvan a generar sus claves públicas y privadas con un sistema actualizado.

Opina sobre esta noticia:
http://www.hispasec.com/unaaldia/3594/comentar

Más información:

Active attacks using stolen SSH keys
http://isc.sans.org/diary.php?storyid=4937

SSH Key-based Attacks
http://www.us-cert.gov/current/#ssh_key_based_attacks

16/05/2008 Preguntas frecuentes sobre el problema critptográfico de Debian
http://www.hispasec.com/unaaldia/3492

14/05/2008 Graves problemas en el algoritmo que genera los números
aleatorios en Debian
http://www.hispasec.com/unaaldia/3490

$ su -
# cd /usr/share/courier-imap
# cp -p pop3d.pem pop3e.pem.`date '+%Y%m%d'`
# rm pop3d.pem
# ./mkpop3dcert

Si fa un gran parlare di sicurezza, di questi tempi. Pare che i Rom siano il problema principale, come se li avessimo tra noi da ieri. Mah...

Ma passando all'informatica, colpisce come la sicurezza sia così poco considerata, nell'ambiente proprietario.

Oggi ho scoperto, per dire, che una falla di sicurezza segnalata come gravissima da Secunia, riguardante Microsoft Access, non è ancora stata patchata.

http://secunia.com/advisories/30883

Leggiamo bene il report:

Description:
A vulnerability has been reported in Snapshot Viewer for Microsoft Access, which can be exploited by malicious people to compromise a user's system.

The vulnerability is caused due to the snapview.ocx ActiveX control reportedly allowing files to be automatically downloaded to arbitrary locations on a user's system when e.g. visiting a malicious website.

Successful exploitation allows execution of arbitrary code.

NOTE: The vulnerability is currently being actively exploited

Tradotto: la vulnerabilità causata dall'ActiveX di Snapshot Viewer compromette chi visita un sito web con tale controllo ActiveX, permettendo all'aggressore di eseguire sulla macchina remota del codice arbitrario e di farle automaticamente scaricare un file (quindi può tranquillamente fare quel che gli pare, in parole povere)
Non solo, la vulnerabilità è già attivamente utilizzata.

Basta fare un confronto con le recenti falle in sistemi open source, come quella dell'OpenSSL di Debian.
Scoperta da Debian stessa, mai usata nella pratica, patchata in poche ore.

Bella differenza no?
Eppure quella falla è considerata "gravissima" e ha messo in ginocchio la reputazione di Debian, pur non avendo causato alcun danno (a parte quelli a Verisign che ha dovuto ricalcolare le chiavi). Le falle dei prodotti Windows rimangono incorrette per mesi, a volte per anni, permettendo ad esempio a vecchi virus di attaccare il nuovissimo Windows Vista. Ma nessuno si scandalizza.
Forse perché è ormai considerato normale che i sistemi Microsoft siano insicuri, al punto che la legge italiana prevede l'obbligo di installare un antivirus per i computer che custodiscono dati sensibili.

Viceversa una falla grave in un sistema GNU/Linux è come quando nevica ad agosto...

openssl rsa -in server.key -out server.pem

I needed this for appache.

Instale os pacotes necessários

aptitude install openssl ssl-cert

Crie o certificado

openssl req $@ -new -x509 -days 365 -nodes -out /etc/apache2/apache.pem -keyout /etc/apache2/apache.pem

Defina a permissão para o arquivo criado

chmod 600 /etc/apache2/apache.pem

Edite o arquivo /etc/apache2/ports.conf e adicione a seguinte linha:

Listen 443

Habilite o suporte a SSL no apache2 da seguinte forma:

a2enmod ssl

Faça uma cópia do arquivo /etc/apache2/sites-available/default com o nome ssl.

cp /etc/apache2/sites-available/default /etc/apache2/sites-available/ssl

Faça um link simbólico para /etc/apache2/sites-enabled/

ln -s /etc/apache2/sites-available/ssl /etc/apache2/sites-enabled/

Edite o arquivo /etc/apache2/sites-available/ssl, adicionando as seguintes linhas:

NameVirtualHost *:443

ServerAdmin webmaster@localhost
.....
CustomLog /var/log/apache2/access.log combined
SSLEngine on #Adicione esta linha
ServerSignature On
SSLCertificateFile /etc/apache2/apache.pem #Adicione esta linha

Reinicie o Apache

apache2ctl restart

Fonte

Este artigo estará disponivel na wiki de documentação do Time de Segurança do Ubuntu-BR

openssl enc -e -bf-cbc -in test.txt -out test.bin \
     -K 12345678911234567892123456789312 \
     -iv 00000000

The above command instructs OpenSSL to perform encryption ("-e") on the file test.txt ("-in test.txt"), using the blowfish with cipher block chaining ("-bf-cbc"). The encrypted data would be placed in the file "test.bin" ("-out test.bin"). The key, in hexadecimal, is 12345678911234567892123456789312 ("-K ...") and the iv is 00000000 (-"iv ..."). Notice that the -K is in capital letters. The lower case k has a different meaning! The key and iv must also expect their parameters to be in hexadecimal. To decrypt the encrypted file on the command line, you also use the enc command. The only differences are that the use '-d' instead of '-e' and you do not need the "-out ..." argument.

 openssl enc -e -bf-cbc -in test.bin \
    -K 12345678911234567892123456789312 \
    -iv 00000000 

The functions for performing encryption and decryption in the OpenSSL crypto library are EVP_EncryptInit_ex, EVP_EncryptUpdate and EVP_EncryptFinal_ex, for encryption, and EVP_DecryptInit_ex, EVP_DecryptUpdate and EVP_DecryptFinal_ex, for decryption. The documentation for these functions include an example for how to perform encryption using the encryption functions. The code for decryption is similar to the code for encryption.

First, start by loading the key, iv and the encrypted data.  The encrypted data can be loaded using the standard combination of fopen, fread and fclose.

int readfile(const char *filePath,
             unsigned char * buf,
             int maxSize)
{
    FILE * inf = NULL;
    int readSize = 0;
    inf = fopen(filePath, "rb") ;

    return readSize;
}

If you are using encrypted data created using the same key and iv combination as above, the key and iv should be specified as follows:

    char key[16] = {0x12, 0x34, 0x56, 0x78, 0x91, 0x12, 0x34, 0x56,
                     0x78, 0x92, 0x12, 0x34, 0x56, 0x78, 0x93, 0x12};
 
    char iv[8];
    memset(iv, 0x00, 8);

Notice that the key and iv are specified in hexadecimal. This is because when the encrypted data as generated, the key and iv were also given in hex! This is also important, as specifying it has a literal string (ie. char *iv = "00000000") is not the same and could result in time spent in trying to debug it fustratingly!

As mentioned before, the code for decrypting is similar to the code for encrypting. The first step is to setup a cipher context and initialise it.

char *decrypt (char *key,
               char *iv,
               char *encryptedData,
               int encryptedLength)
{
    // Initialisation
    EVP_CIPHER_CTX *cryptCtx = EVP_CIPHER_CTX_new();
    EVP_CIPHER_CTX_init(cryptCtx);

    int decryptResult = EVP_DecryptInit_ex(cryptCtx,
        EVP_bf_cbc(), NULL, key, iv);

Next, use the EVP_DecryptUpdate function to attach the encrypted data and to decrypt the data.

    // EVP_DecryptInit_ex returns 1 if it succeeded.
    if (decryptResult == 1)
    {
        decryptResult = EVP_DecryptUpdate(cryptCtx, decryptedData,
            &decryptedLength, encryptedData, encryptedLength);

Note that EVP_DecryptUpdate will alter the value of the third parameter to be equal to the amount of data that was written. This is not always the entire length of the decrypted data! To finish the decryption process, use EVP_DecryptFinal_ex. This will decrypt any remaining data.

        // Cleanup
        if (decryptResult == 1)
        {
            // Stick the final data at the end of the last
            // decrypted data.
            EVP_DecryptFinal_ex(cryptCtx,
                decryptedData + decryptedLength,
                &lastDecryptLength);

    EVP_CIPHER_CTX_free(cryptCtx);
    EVP_cleanup();
    return decryptedData;
}

In the call to EVP_DecryptFinal_ex, note that the pointer that is given is the start of the decrypted memory buffer plus the length that was given back by the call to EVP_DecryptUpdate. This to prevent it from writing over what was originally decrypted. The resulting decrypted data is NOT guaranteed to be always null terminated. This is why a null has also been explicitly set in the above code.

$KUNDE warf mir nochmal 50 SSL-Zertifikate vor die Füße, zwecks Überprüfung, von denen 38 für das Debian-SSL-Problem empfänglich waren. Aber ich hab ja mittlerweile Routine.

Also wurden neue CSRs generiert, welche er bei Verisign (RSA/"Secure Server Certification Authority") zum Re-Issue eingereicht hat. Minuten später kam der erste mit einer Firefox-Fehlermeldung um die Ecke:

Die verantwortliche Konfigurationsoption war dann auch schnell identifiziert:

Willkommen im Dilemma. So schwer es mir fällt, zu bestreiten, daß diese Voreinstellung in Firefox 3.0 auf den Tag genau zur rechten Zeit kommt, so unangebracht finde ich es, daß Verisign ein Zertifikat, dessen Austausch es gerade mal so mit Ach und Krach in die Mailbox der Administratoren geschafft hat, sofort per OCSP als gesperrt propagiert.

Gerade weil es jetzt so weit ist, daß OCSP, das Online Certificate Status Protokoll, tatsächlich genutzt wird, wäre eine gewisse Galgenfrist von mindestens 1 Tag bis vielleicht 1 Woche mehr als angemessen. Insbesondere bei einer Massenaktion mit einem Umfang von mehreren Dutzend Zertifikaten ist mir persönlich nämlich schleierhaft, wie man die Zertifikate im Rahmen von Change-Prozessen derart schnell auf die Produktivserver katapultieren soll.

Wenn man nochmal 30 Sekunden drüber nachdenkt, kommt man übrigens zur Erkenntnis, daß es auch mit einem einzigen Zertifikat kaum sauber hinzubekommen ist. Auf einer hochgradig produktiven SSL-Site muß man, wenn die CA einen OCSP Distribution Point bereitstellt, in Zukunft auf den Re-Issue verzichten und additiv ein neues Zertifikat dazukaufen, um es überhaupt ohne Ausfall tauschen zu können. Ob das wirklich im Sinne des Erfinders ist?

apaan sih checksum?

checksum itu adalah salah satu skema dari "redundary check"(RC). RC adalah proses pendeteksian dan pengkoreksian error dari sebuah data, ini merupakan sebuah solusi mudah buat ngelindungin integritas/keaslian dari sebuah data yang dikirim via jaringan internet. jadi singkat cerita...checksum itu adalah salah satu "teknik" buat ngecek+ngoreksi error dari sebuah data untuk ngetes keaslian dari data tersebut.

cara kerja checksum?
cara kerjanya adalah dengan menambahkan data tambahan (biasanya berupa bit-bit) terhadap data, dan nilai hasil dari proses penggabungan itu nantinya bisa digunain ama penerima data yang kemudian akan membandingkan hasil dari ototentikasi checksum tersebut, dan apabila sama dengan hasil checksum di sumber maka akan menghasikan kesimpulan kalo data yang diterima ga korup, disisipi virus/trojan, atau lain kata: data yang diterima adalah asli!!!

beberapa skema pengecekan error:
repetition schemes
parity schemes
checksum
cylic redundancy checks
hamming distance based checks
hash function
horizontal and vertical redundancy check
polarity scheme

POC (proof of concept)

praktek!!! setelah puyeng ama teori diatas, mari kita praktekin aja langsung...kali aja malah tambah puyeng :P

kali ini saya bakal bahas cara ngecek integritas data pake program bawaan UNIX (mac os x termasuk keluarga unix...) yaitu sha1:

* buka terminal (kalo di windows ... command prompt)

* ketikin: /usr/bin/openssl sha1 [path file]

contoh: kanabies:~ sgk$ /usr/bin/openssl sha1 /Users/sgk/Documents/test-checksum.txt

kemudian sha-1 digest (hasil RC) akan menampilkan: sha1 ([full path to the file])= [checksum amount]

contoh: SHA1(/Users/sgk/Documents/test-checksum.txt)= da39a3ee5e6b4b0d3255bfef95601890afd8070

nah sekarang kalo hasil hash (da39a3ee5e6b4b0d3255bfef95601890afd8070) nya sama dengan hash sumber maka bisa ditarik kesimpulan kalo data yang anda dapatkan itu asli...

CMIIW

=====================================================================

faq

apa itu redundary check???
apa itu checksum???
gimana cara kerja checksum???
ada berapa skema RC???
pertanyaan kamu ga ada di daftar faq???
coba cari disini, disana, baru kesini (semoga aja bisa jawab :p)

1. Given M, it is easy to compute h
2. Given h, it is hard to compute M such that H(M) = h
3. Given M, it is hard to find another messag, M1 , such that H(M) = H(M1)

SHA-*, MD* and RIPEMD-* are the most popular Hash functions. OpenSSL provides both generic APIs to these Hash functions also provides direct APIs. Accessing through generic API (the EVP) is preferred.

Now let us first use the Hash APIs from OpenSSL and generate fingerprint or calculate hash value. The alorithm, that we will use, is MD5. MD5 (MD stands for Message Digest ) is One way hash algorithm from Ron Rivest. There are test vectors in MD5 RFC, which we can use to calculate (or validate) the hash values. The following figure shows the process of calculation MD5 hash using OpenSSL :-

Below is an example to calculate message digest using MD5 algorithm.

Code Snippet :

openSSlExmpleHashMd5.cpp

#include <stdio.h>
#include <string.h>
#include <openssl/evp.h>

int main(int argc, char *argv[  ]) {

	int i,j;
	const int	totalTestVectors = 7;
	/*
	The ouput length for the claculated
	digest. This will be fixed for a parti-
	cular Hash algorithm and will very algo-
	rithm to algorithm.
	*/
  unsigned int	outputLength;
	/*
	The Message Digest Context object, which
	will hold the intermediate state.
	*/

  EVP_MD_CTX    messageDigestContext;

	/*
	The buffer to store message digest after
	computing. 64 bytes is enough for any hash
	function. For MD5 128/8 would be fine as
	MD5 has 128 bit output length.
	Someone can directly use the 128/8 as
	the size but if you change the Hash
	algorithm, for example SHA1,has 160 bit
	output, the length need to be changed to
	160/8 bytes.
	*/

  unsigned char messageDigest[EVP_MAX_MD_SIZE];

  /*
  Hashes will be calculated for the following strings.
  These strings are from the MD5 RFC.
  */
  const char *strMessages[] =
  {	"", // Input String : 1
        "a", // Input String : 2
	"abc",// Input String : 3
	"message digest",// Input String : 4
	"abcdefghijklmnopqrstuvwxyz",// Input String : 5
	"ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789",// Input String : 6
	"12345678901234567890123456789012345678901234567890123456789012345678901234567890"};// Input String : 7
	  /*
	  For each Input string the Expected Output are (from RFC,
	  this is to make sure that, this implementation is not bogus):
	  1: d41d8cd98f00b204e9800998ecf8427e
	  2: 0cc175b9c0f1b6a831c399e269772661
	  3: 900150983cd24fb0d6963f7d28e17f72
	  4: f96b697d7cb7938d525a2f31aaf161d0
	  5: f96b697d7cb7938d525a2f31aaf161d0
	  6: d174ab98d277d9f5a5611c2c9f419d9f
	  7: 57edf4a22be3c955ac49da2e2107b67a
	  */

	/*
	Initialize the Message Digest Context
	Calculate Message Digest
	*/
	//EVP_DigestInit(&messageDigestContext, EVP_md5());
  for (j=0;j<totalTestVectors; j++)
  {
	  EVP_DigestInit(&messageDigestContext, EVP_md5()); // for SHA1 use EVP_sha1()
	  EVP_DigestUpdate(&messageDigestContext, strMessages[j], strlen(strMessages[j]));
	  EVP_DigestFinal(&messageDigestContext, messageDigest, &outputLength);
	  printf("Test Vector : \"%s\" \n, Digest : = \"",strMessages[j]);
	  for (i = 0;  i < outputLength;  i++) printf("%02x", messageDigest[i]);
	  printf("\"\n");
  }
  return 0;
}

The above code work fine on windows or Linux but you should have

already openssl libs with you or you can download it.

Here is the URL (it's linked from the homepage as well): http://lockup.wordpress.com/configure-openvpn/

As I mentioned in a previous post, using this configuration of OpenVPN, you'll be able to securely connect to your host network from anywhere, access files, services and the host internet connection, but you're host network will remain completely invisible to ports scans.

This product is amazingly effective, simple to use (once setup) and, with the right configuration, secure. I think my guide is fairly comprehensive, but if you have any suggestions, feel free to comment.

Big thanks to Riley at It's a Tech World for writing such a great guide.

Ubuntu 8.04 Hardy Heron

As vulnerabilidades permitem que um atacante remoto envie pacotes forjados causando um DoS. O Ubuntu 8.04 LTS não compila extensões do servidor TLS por padrão. (CVE-2008-0891)

Para maiores informações sobre estas e outras vulnerabilidades acessem a seção ALERTAS na wiki page do Time de Segurança

The OpenSSL documentation on BIO_f_base64 actually provides an example of how to use the library to perform the decoding with the library. The example on that page:

    BIO *bio, *b64, *bio_out;
    char inbuf[512];
    int inlen;  

    b64 = BIO_new(BIO_f_base64());
    bio = BIO_new_fp(stdin, BIO_NOCLOSE);
    bio_out = BIO_new_fp(stdout, BIO_NOCLOSE);
    bio = BIO_push(b64, bio);  

    while((inlen = BIO_read(bio, inbuf, 512)) > 0)
        BIO_write(bio_out, inbuf, inlen);

In the example, three BIOs are created - for decoding, outputting to standard output and another for taking in encoded data. The call to BIO_push creates a BIO chain (it adds the input BIO to the base 64 BIO) and then we loop until all of the decoded data is read. In each iteration, the decoded data is, first, read into the character array inbuf before it is outputted to standard output by writing to the BIO bio_out. In the example, each chunk of decoded data is outputted to standard output, but it is likely that you would want to store the decoded data in memory for some sort of processing. The most obvious way of doing this is to allocate memory to hold the entire decoded data and append each decoded chunk of data during each iteration of the loop.

If you are using C++, you can easily use C++ string to hold the decoded data and append during each loop. If you are using just C, one possibility around this problem is to allocate some initial memory and then use realloc to resize the memory during each iteration of the loop to hold in more and more data. But this seems rather inefficient because of the need to increase the size of the allocated memory. Note that realloc could also have to move the memory. We could avoid having to resize the memory during each iteration by allocating the memory before reading back the decoded data. Another inefficient method is to perform the loop twice - once to determine the length of the decoded data and another time to store the decoded data. It is more efficient to simply allocate the memory first and then read through the loop once, but how do you know the length of decoded data?

To determine exactly how long the decoded data should be, you have to go back to how base 64 encoding works - a group of 24 bits is mapped to a group of four ASCII characters. Note that valid base 64 encoded data will always have a length that is divisible by four. If the length of base 64 encoded data is not divisible for four, there is something wrong with the encoded data. For are given encoded data with x number of ASCII characters, the number of bits, y, in the decoded data is found as follows:

        24 bits = 4 ASCII characters
        y bits = x ASCII characters
        y = (24 * x) / 4 = (6 * x) bits

Next, we have to account for padding. Padding is present when the last group of 24 bits in the data that was encoded did fully occupy 24 bits. The base 64 standard states that there are three possibilities for padding - there will be either no, only one or only two padding characters (see the bottom of page 5 in RFC 4648). Also, note that the standard uses the equal sign ("=") as the padding character. For each instance of this padding character at the end of the encoded data, subtract eight bits from y to get the final expected decoded length.

Now that the calculation has been explained, we can turn this into code:

     char *encoded = "WU9ZTyEA";
     int result = 0;
     int padding = 0;
     int strLength = strlen(encoded);

     // Check that the string is not empty and that the length is a multiple of four.
     if ((strLength > 0) && ((strLength % 4) == 0))
     {
         // First, we check if the last character is padding.
         if (encoded[strLength - 1] == PADDING_CHAR)
         {
             padding++;

             // The second last character could also be padding!
             if (encoded[strLength - 2] == PADDING_CHAR)
             {
                 padding++;
             }
         }

         // Now that we know the amount of padding, we can caculate the expected
         // length. If groups of 24 bits (3 characters) get encoded into 32 bits
         // (4 characters) ...
         result = (3 * strLength) / 4;

         // Accounting for the padding:
         result = result - padding;
     }
     else
     {
         printf("Either there is no data to decode or its length is incorrect.\n");
     }

Note one important assumption was made in this code ... that one char occupies 8 bits!

There is also one thing that I have come across when using OpenSSL to perform base 64 decoding. If the encoded data is greater than 64 characters long, I have had to insert a newline character after every 64 characters. This could be because OpenSSL mainly deals with the PEM format, which uses base 64 encoding. The PEM format uses line lengths of 64 characters (see RFC 4648, section 3.1). I have also had to make sure that the last line of the encoded data has a newline character at the end.

Auch zu empfehlen als kleiner Warnschuß an Anwender, die sich weigern, Zertifikate auszutauschen: "Firefox zeigt bereits eine Warnmeldung an. Was wirst Du Deinen Kunden erzählen, wenn der Internet Explorer das nach dem nächsten Microsoft-Patchday ebenfalls macht?"