Secure Sockets Layer (SSL) und Transport Layer Security (TLS)
Architektur
Das SSL Protokoll setzt auf dem TCP Protokoll auf um eine gesicherte Verbindung aufzubauen.- SSL Stack
Record Protokoll
Das Record Protokoll stellt die untere Schicht des SSL Protokolls dar. Es stellt die zwei grundlegenden Dienste des SSL Protokolls bereit:- Vertraulichkeit durch symmetrische Verschlüsselung
- Nachrichtenintegrität durch kryptografische Prüfsummen
- Record Protokoll:
- Content Type: höheres SSL Protokoll ( Handshake, Change Cipher, Alert oder Application Data)
- Major, Minor Version: SSL Version
- Compressed Length: Länge der Daten
- Plaintext: symmetrisch verschlüsselte Nutzdaten (höhere SSL Protokoll)
- Massage Authentication Code MAC: Prüfteil zur Authentifizierung der gesendeten Nachricht
- Fragmentierung
- Komprimierung:
- Handshake Protokoll: (ein/aus)
- Hinzufügen der MAC
- Verschlüsselung
- Anhängen des Headers
- Fragmentierung Record Protokoll:
Handshake Protokoll
Das Handshake Protokoll dient dazu, die Kommunikationspartern zu authentifizieren und die Algorithmen und Schlüssel für die weitere SSL Sitzung auszuhandeln.Serverauthentifizierung
Das Handshake Protokoll durchläuft vier verschiedene Phasen:
- Aushandeln der Sicherheitsressourcen
- zu verwendende SSL Version
- Zufallszahl des Servers und Clients
- Cipher Suite
- Datenkompression
- Serverauthentifizierung und Schlüsselaustausch
- Serverzertifkat an den Client
- Clientauthentifizierung und Schlüsselaustausch
- Clientzertifikat
- Pre master secret wird an den Server geschickt
- Beendigung
- Umstellung auf die ausgehandelten Sicherheitsressourcen
Server- und Clientauthentifizierung
in voller Größe mit den verwendeten Zufallszahlen, Geheimnissen und Schlüsseln: http://upload.wikimedia.org/wikipedia/commons/a/ae/SSL_handshake_with_two_way_authentication_with_certificates.svg
- RN: Random Number
- PMS: Pre Master Secret
- MS: Master Secret
Change Cipher Spec Protokoll
Bewirkt, das der Empfänger der Nachricht auf die durch den Handshake ausgehandelten Cipher umstellt. Im Handshake Protokoll wird eine Cipher ohne Verschlüsselung gewählt.Alert Protokoll
Das Alert Protokoll wird zu Übermittlung von Fehler verwendet. Diese können vom Typ warning oder fatal sein. Nachrichten vom Typ fatal zeichnen sich dadurch aus, das durch sie die Sitzung sofort beendet wird. Nachrichten vom Typ warning können als fatal interpretiert werden.- fatal:
- unexpected_message
- bad_record_mac
- decompression_failure
- handshake_failure
- illegal_parameter
- warning
- close_notify
- no_certificate
- bad_certificate
- unsupported_certificate
- certificate_revoked
- certificate_expired
- certificate_unknown
Application Data Protokoll
Die Anwendungsdaten (z.B.: http), die im Gegensatz zu den anderen SSL Protokollen nicht geprüft werden.Variationen
Rehandshake
Erst beim Daten übertragen weiß der Server, wie kritisch die zu übertragenden Daten sind. In dieser Phase der SSL Sitzung ist aber schon die Cipher Suite und die Verifizierung der Kommunikationsteilnehmer abgeschlossen.Der Sicherheitskontext muß neu ausgehandelt werden.
Durch das Senden eines ClientHello Nachricht kann der Client eines neuen Handshake initiieren. Auf eine HelloRequest Anfrage des Servers antwortet der Client wiederum mit einem ClientHello. Weder der Client noch der Server müssen auf einen Rehandshake eingehen.
- Gründe
- Cipher Suite neu verhandeln
- Client fordert sensible Daten
- Client wechselt Rolle; vom Lese- zum Schreibzugriff
- einfacherer Sicherheitskontext ist für den Client ausreichend
- Cipher Suite erneuern, da die Session schon lange besteht
- Clientzertifikat anfordern
- weitere Zugriff auf den Server verlangt die Authentifizierung des Clients
- Cipher Suite neu verhandeln
Clientauthentifizierung
Vor der ServerHelloDone Nachricht, die als letzte Antwort auf das initiale ClientHello folgt, kann der Server ein Clientzertifikat mittels CertificateRequest anfordern.Sitzungswiederaufnahme
Um den teueren Handshake zu vereinfachen, erlaubt das SSL Protokoll die Wiederaufnahme einer alten Sitzung. Damit der Client session resumption verwenden kann, muß dies vom Server angeboten werden.Wie funktioniert nun das ganze?
- Alte Sitzung
- Server schickt im ServerHello die Session ID mit, die nicht NULL sein darf
- Client und Server merken sich die Session ID und das Master Secret
- Verbindung muß sauber heruntergefahren werden
- Neue Sitzung
- Client schickt beim ClientHello die alte Session ID mit allen zusätzlichen Parametern mit
- Server schickt die
- alte Session ID zurück Session kann wieder aufgenommen werden (verkürzter Handshake)
- neue Session ID Session muß neu ausgehandelt werden (voller Handshake)
- Client und Server leiten aus dem alten Master Secret und den neuen Zufallszahlen, die beim ClientHello und ServerHello übermittelt wurden, die Schlüsselgeheimnisse ab
- beide Seiten senden ChangeCipherSpec ,beeden den Handhake und können die Nutzdaten austauschen
- Unterschiede zum normalenHandshake
- Client und Server erzeugen kein Master Secret
- weniger Roundtrips
- Client
- baut sich einen Session Cache auf (geringer Aufwand)
- spart sich
- Überprüfen der Signatur der CA
- Erzeugen des Pre Master Secret
- Verschlüsseln des Pre Master Secret mit dem öffentlichen Schlüssel des Servers
- der Server
- Aufbau eines Session Caches (hoher Aufwand)
- Speicher (50-100 Byte je Session)
- CPU Zeit um den Cache auszulesen
- Synchronisation der Zugriffe aus verschiedenen Prozessen/Threads
- spart sich
- Entschlüsseln des pre_master_secret mit den geheimen Schlüssel des Masters (rechenintensiv)
- Überprüfen der Signatur der CA bei einem Clientzertifikat
- Aufbau eines Session Caches (hoher Aufwand)
- Fazit aus SSL and TLS von Eric Rescorla
"The moral of the story is that session resumption is nearly always worth doing on the client.
On the server, however, it's only worth doing if there is a lot of repeat business
within a fairly short period of time. Even in such situations's, it's worth asking
whether the protocol can be converted to simply leave those connections up
rather than incurring even the minimal cost of a resumed handshake."
Performance
Grundlage sind die zwei C-Programme wserver2 und wclient2 von Eric Rescorla, die eine SSL Verbindung aufbauen. Als Ergebnis erhält der Client eine AntwortHTTP/1.0 200 OK
. Jede Anfrage wird 100 mal ausgeführt und das arithmetische Mittel berechnet. Der SSL-Client läuft auf der gleichen Maschine wie der SSL-Server.
for cipher in allCiphers:
begin=time.time()
for i in xrange(number):
err=subprocess.Popen(["wclient2","-a",cipher,"-i"],stderr=subprocess.PIPE).communicate()[1]
if ( err ):
statWithoutServ.add( ((cipher,None),))
break
else:
statWithoutServ.add( ((cipher,time.time()-begin),))
Cipher Suites
- von openSSL angeboten
grimm@sydney ciphersTest $ openssl ciphers
DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:AES256-SHA:EDH-RSA-DES-CBC3-SHA:EDH-DSS-DES-CBC3-SHA:
DES-CBC3-SHA:DES-CBC3-MD5:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:AES128-SHA:RC2-CBC-MD5:
DHE-DSS-RC4-SHA:EXP-KRB5-RC4-MD5:EXP-KRB5-RC4-SHA:KRB5-RC4-MD5:KRB5-RC4-SHA:RC4-SHA:RC4-MD5:
RC4-MD5:KRB5-DES-CBC3-MD5:KRB5-DES-CBC3-SHA:RC4-64-MD5:EXP1024-DHE-DSS-DES-CBC-SHA:
EXP1024-DES-CBC-SHA:EXP1024-RC2-CBC-MD5:KRB5-DES-CBC-MD5:KRB5-DES-CBC-SHA:EDH-RSA-DES-CBC-SHA:
EDH-DSS-DES-CBC-SHA:DES-CBC-SHA:DES-CBC-MD5:EXP1024-DHE-DSS-RC4-SHA:EXP1024-RC4-SHA:
EXP1024-RC4-MD5:EXP-KRB5-RC2-CBC-MD5:EXP-KRB5-DES-CBC-MD5:EXP-KRB5-RC2-CBC-SHA:EXP-KRB5-DES-CBC-SHA:
EXP-EDH-RSA-DES-CBC-SHA:EXP-EDH-DSS-DES-CBC-SHA:EXP-DES-CBC-SHA:EXP-RC2-CBC-MD5:EXP-RC2-CBC-MD5:EXP-RC4-MD5:
EXP-RC4-MD5 - von meinem Setup
- nicht unterstützt
'DHE-DSS-AES256-SHA', 'EDH-DSS-DES-CBC3-SHA', 'DES-CBC3-MD5', 'DHE-DSS-AES128-SHA', 'RC2-CBC-MD5',
'DHE-DSS-RC4-SHA', 'EXP-KRB5-RC4-MD5', 'EXP-KRB5-RC4-SHA', 'KRB5-RC4-MD5', 'KRB5-RC4-SHA', 'KRB5-DES-CBC3-MD5',
'KRB5-DES-CBC3-SHA', 'RC4-64-MD5', 'EXP1024-DHE-DSS-DES-CBC-SHA', 'KRB5-DES-CBC-MD5', 'KRB5-DES-CBC-SHA',
'EDH-DSS-DES-CBC-SHA', 'DES-CBC-MD5', 'EXP1024-DHE-DSS-RC4-SHA', 'EXP-KRB5-RC2-CBC-MD5','EXP-KRB5-DES-CBC-MD5',
'EXP-KRB5-RC2-CBC-SHA', 'EXP-KRB5-DES-CBC-SHA', 'EXP-EDH-RSA-DES-CBC-SHA', 'EXP-EDH-DSS-DES-CBC-SHA',
'EXP-DES-CBC-SHA', 'EXP-RC2-CBC-MD5', 'EXP-RC2-CBC-MD5', 'EXP-RC4-MD5' - unterstützt
'DES-CBC3-SHA','AES256-SHA','RC4-SHA','AES128-SHA','RC4-MD5','EXP1024-RC2-CBC-MD5','RC4-MD5','EXP1024-DES-CBC-SHA',
'DES-CBC-SHA','EXP1024-RC4-SHA','EXP1024-RC4-MD5','EDH-RSA-DES-CBC3-SHA','DHE-RSA-AES256-SHA','DHE-RSA-AES128-SHA',
'EDH-RSA-DES-CBC-SHA'
- nicht unterstützt
SSL Verbindungen
- Ohne Serverauthentifizierung
['DES-CBC3-SHA'] : 0.024735 s
['AES256-SHA'] : 0.027918 s
['RC4-SHA'] : 0.030478 s
['AES128-SHA'] : 0.030531 s
['RC4-MD5'] : 0.030736 s
['EXP1024-RC2-CBC-MD5'] : 0.031082 s
['RC4-MD5'] : 0.031537 s
['EXP1024-DES-CBC-SHA'] : 0.031818 s
['DES-CBC-SHA'] : 0.032003 s
['EXP1024-RC4-SHA'] : 0.034153 s
['EXP1024-RC4-MD5'] : 0.037164 s
['EDH-RSA-DES-CBC3-SHA'] : 0.044309 s
['DHE-RSA-AES256-SHA'] : 0.052077 s
['DHE-RSA-AES128-SHA'] : 0.054840 s
['EDH-RSA-DES-CBC-SHA'] : 0.060272 s - Mit Serverauthentifizierung
['RC4-MD5'] : 0.036252 s
['RC4-MD5'] : 0.036432 s
['AES128-SHA'] : 0.038238 s
['EXP1024-DES-CBC-SHA'] : 0.038395 s
['RC4-SHA'] : 0.038639 s
['DES-CBC3-SHA'] : 0.040057 s
['AES256-SHA'] : 0.041349 s
['DES-CBC-SHA'] : 0.041775 s
['EXP1024-RC2-CBC-MD5'] : 0.043131 s
['EXP1024-RC4-MD5'] : 0.043935 s
['EXP1024-RC4-SHA'] : 0.044073 s
['DHE-RSA-AES128-SHA'] : 0.086921 s
['EDH-RSA-DES-CBC3-SHA'] : 0.099549 s
['EDH-RSA-DES-CBC-SHA'] : 0.109368 s
['DHE-RSA-AES256-SHA'] : 0.118780 s - Vergleich in Millisekunden
cipher suite without with Server authentication difference
EXP1024-RC4-SHA 0.034153 0.044073 0.00992
DES-CBC-SHA 0.032003 0.041775 0.009772
DHE-RSA-AES256-SHA 0.052077 0.118780 0.066703
EDH-RSA-DES-CBC3-SHA 0.044309 0.099549 0.05524
RC4-SHA 0.030478 0.038639 0.008161
DHE-RSA-AES128-SHA 0.054840 0.086921 0.032081
EXP1024-RC4-MD5 0.037164 0.043935 0.006771
EXP1024-RC2-CBC-MD5 0.031082 0.043131 0.012049
EXP1024-DES-CBC-SHA 0.031818 0.038395 0.006577
AES256-SHA 0.027918 0.041349 0.013431
EDH-RSA-DES-CBC-SHA 0.060272 0.109368 0.049096
AES128-SHA 0.030531 0.038238 0.007707
DES-CBC3-SHA 0.024735 0.040057 0.015322
RC4-MD5 0.031537 0.036432 0.004895 - der Komplettanfrage benötigt
- 24 - 60 Millisekunden ohne Serverauthentifizierung
- 36 - 118 Millisekunden mit Serverauthentifizierung
- Annahme: (50-180 Millisekunden mit Client- und Serverauthentifizierung)
- abhängig von der Cipher Suite kann die Anfrage um den Faktor 3 teurer werden
Sitzungswiederaufnahme
Durch eine kleine Modifikation des Clientprogramms wclient2 kann ich nun die Zeit für den ersten Handshake (startFirst - finishFirst) mit dem zweiten Handshake (startSecond - finishSecond) vergleichen.Der zweite Handshake benützt die Session des ersten (
SSL_set_session(ssl,sess); /*And resume it*/
) Handshake. /* Connect the SSL socket */
ssl=SSL_new(ctx);
sbio=BIO_new_socket(sock,BIO_NOCLOSE);
SSL_set_bio(ssl,sbio,sbio);
gettimeofday(&startFirst, (struct timezone *)NULL);
if(SSL_connect(ssl)<=0)
berr_exit("SSL connect error");
if(require_server_auth)
check_cert(ssl,host);
gettimeofday(&finishFirst, (struct timezone *)NULL);
/* Now hang up and reconnect, if requested */
if(reconnect) {
sess=SSL_get1_session(ssl); /*Collect the session*/
SSL_shutdown(ssl);
SSL_free(ssl);
close(sock);
sock=tcp_connect(host,port);
ssl=SSL_new(ctx);
sbio=BIO_new_socket(sock,BIO_NOCLOSE);
SSL_set_bio(ssl,sbio,sbio);
SSL_set_session(ssl,sess); /*And resume it*/
gettimeofday(&startSecond, (struct timezone *)NULL);
if(SSL_connect(ssl)<=0)
berr_exit("SSL connect error (second connect)");
check_cert(ssl,host);
gettimeofday(&finishSecond, (struct timezone *)NULL);
printElapsedTime(startFirst,finishFirst,"First: ");
printElapsedTime(startSecond,finishSecond,"Second: ");
}
- die Ergebnisse in Millisekunden
Cipher Suite First Handshake Second Handshake with session resumption
EDH-RSA-DES-CBC3-SHA 37.800000 36.600000
EXP1024-DES-CBC-SHA 14.300000 11.300000
AES256-SHA 6.300000 5.100000
EDH-RSA-DES-CBC-SHA 42.200000 41.300000
DHE-RSA-AES128-SHA 49.400000 49.900000
EXP1024-RC4-SHA 13.900000 11.300000
RC4-MD5 14.300000 12.000000
DES-CBC-SHA 7.900000 6.900000
AES128-SHA 27.500000 23.200000
DHE-RSA-AES256-SHA 28.200000 29.100000
EXP1024-RC2-CBC-MD5 14.000000 11.500000 - der Handshake mit Sitzungswiederaufnahme ist maximal um 30% schneller
Schlüsselwahl und Schlüssellänge
openSSL liefert eine eigene Performance Suite mit.grimm@sydney auswertung $ openssl speed
...
...
...
The 'numbers' are in 1000s of bytes per second processed.
type 16 bytes 64 bytes 256 bytes 1024 bytes 8192 bytes
md2 1124.06k 1654.45k 2174.27k 2569.77k 2824.63k
mdc2 0.00 0.00 0.00 0.00 0.00
md4 7679.28k 30622.65k 139356.81k 229721.21k 308016.46k
md5 10751.59k 31822.73k 76900.35k 143188.37k 179535.06k
hmac(md5) 3355.47k 12968.15k 40527.28k 87899.88k 162025.07k
sha1 6461.14k 20570.64k 47667.11k 75183.99k 87872.65k
rmd160 5368.93k 16108.91k 37371.81k 56029.92k 64101.71k
rc4 86231.87k 94004.96k 94844.39k 89534.38k 82018.30k
des cbc 22620.54k 25906.38k 26350.62k 26655.37k 25599.31k
des ede3 7841.17k 7320.43k 7159.52k 7597.71k 8897.91k
idea cbc 0.00 0.00 0.00 0.00 0.00
rc2 cbc 17617.52k 14671.79k 13253.18k 11784.26k 12852.40k
rc5-32/12 cbc 0.00 0.00 0.00 0.00 0.00
blowfish cbc 51854.28k 61625.97k 65009.87k 61154.84k 53332.93k
cast cbc 20926.86k 23977.11k 34412.74k 32141.47k 27932.25k
aes-128 cbc 23609.05k 39013.39k 29787.40k 37886.92k 37258.53k
aes-192 cbc 29937.03k 31697.97k 36923.42k 37839.06k 38774.55k
aes-256 cbc 29807.40k 30843.84k 30898.77k 32854.67k 35258.48k
sign verify sign/s verify/s
rsa 512 bits 0.001049s 0.000066s 953.0 15180.1
rsa 1024 bits 0.004070s 0.000186s 245.7 5370.6
rsa 2048 bits 0.023373s 0.000508s 42.8 1968.1
rsa 4096 bits 0.145441s 0.001567s 6.9 638.0
sign verify sign/s verify/s
dsa 512 bits 0.000457s 0.000663s 2186.2 1508.4
dsa 1024 bits 0.001159s 0.002143s 863.1 466.6
dsa 2048 bits 0.004459s 0.005694s 224.3 175.6
- Anmerkungen:
- Algorithmen:
- Hashalgorithmen: md2 - rmd160
- symmetrische Verschlüsselungsalgorithmen: rc4 - aes-256 cbc
- asymmetrische Verschlüsselungsalgorithmen: rsa - dsa
- Datenblöcken:
- erster Block (16 bytes bis 8192 bytes): Durchsatz der Verschlüsselungsalgorithmen in einer Sekunde
- zweiter Block
- ersten und zweite Spalte (sign verify): Zeit, die der asymmetrische Verschlüsselungsalgorithmus benötigt, einen Block der Länge (512-2048) zu verschlüsseln bzw. entschlüsseln
- dritte und vierte Spalte (sign/s verify/s): Durchsatz auf eine Sekunde umgerechnet
- Ergebnisse:
- je größer die Blöcke, desto höher der Durchsatz
- Hashalgorithmen:
- md5 ist doppelt so schnell wie sha1
- symmetrische Algorithmen
- rc4 ist mit Abstand der schnellste Algorithmus; des ede3 (Triple DES) der langsamste
- asymmetrische Algorithmen
- der Durchsatz hängt extrem stark von der Schlüssellänge ab
- rsa ist deutlich schneller als dsa
- rsa: das Verschlüsseln ist langsamer als das Entschlüsseln
- dsa: das Verschlüsseln ist schneller als das Entschlüsseln
- Durchsatzvergleich der symmetrischen mit der asymetrischen Verschlüsselung
- symmetrisch: 8000k - 80000k
- asymmetrisch: 7k - 2000k
- Algorithmen:
Faustregeln
- Basic SSL Performance Rulesaus SSL and TLS von Eric Rescorla
- Assymetric algorithm choice. Use RSA.
- Private key size. Use the shortest private keys with wich you feel safe. 768 is good enough for most applications.
- Symmetric algorithm choice. Use RC4 for best performance, 3DES for best security. Export versions compromise security without improving performance.
- Digest algorithm choice. MD5 only improves performance about 40% over SHA-1. In most cases SHA-1 will be fast enough. Stick with SHA-1 for security.
- Session resumption. Client should always use session resumption. Server should use it only if clients tend to reconnect within five to ten minutes.
- Record size. Send data in the largest chunks possible.
Anforderungen
-
- Sicherheitsfunktionen und Schlüssellängen
- Symmetrische Verschlüsselung
- AES, mindestens 256 bit Länge
- Triple DES, mindestens 112 bit Länge
- RC4, mindestens 128 bit Länge
- Asymmetrische Verschlüsselung
- DSA, mindestens 1024 bit Länge
- RSA, mindestens 1024 bit Länge
- ECDSA, mindestens 192 bit Länge
- Hashing Functions
- Secure Hashing Standard FIPS-PUB 180-2 (Algorithmus SHA-1)
- MD5
- Keyed Hashing Functions
- HMAC-SHA-1, mindestens 160 bit Länge
- HMAC-MD5, mindestens 128 bit Länge
- Symmetrische Verschlüsselung
- Sicherheitsfunktionen und Schlüssellängen
Quellen
- http://www.repges.net/SSL/ssl.html
- http://en.wikipedia.org/wiki/Transport_Layer_Security
- Eric Rescorla: SSL and TLS: designing and building secure systems. Addison-Wesley, Boston 2001. ISBN 0-201-61598-3
Weiterlesen...