Inhaltsverzeichnis[Anzeigen]

 

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
    SSLStack.gif
Genauer betrachtet, besteht das SSL Protokoll aus mehreren Teilprotokollen.

 

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:
    RecordProtokoll.gif
Das Protokoll besteht aus den folgenden Komponenten:
  1. Content Type: höheres SSL Protokoll ( Handshake, Change Cipher, Alert oder Application Data)
  2. Major, Minor Version: SSL Version
  3. Compressed Length: Länge der Daten
  4. Plaintext: symmetrisch verschlüsselte Nutzdaten (höhere SSL Protokoll)
  5. Massage Authentication Code MAC: Prüfteil zur Authentifizierung der gesendeten Nachricht
Jedes höherwertige SSL Protokoll durchläuft die folgenden Schritte. Insbesondere wird die Sicherheit der einzelnen Schritte durch das Handshake Protokoll vorgegeben.
  1. Fragmentierung
  2. Komprimierung:
    • right Handshake Protokoll: (ein/aus)
  3. Hinzufügen der MAC
    • Hashfunktion right Handshake Protokoll: SHA1 und MD5
  4. Verschlüsselung
  5. Anhängen des Headers
  • Fragmentierung Record Protokoll:
    FragmentierungRecordProtokoll.gif

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

fig2SSL.gif
Das Handshake Protokoll durchläuft vier verschiedene Phasen:
  1. Aushandeln der Sicherheitsressourcen
    1. zu verwendende SSL Version
    2. Zufallszahl des Servers und Clients
    3. Cipher Suite
    4. Datenkompression
  2. Serverauthentifizierung und Schlüsselaustausch
    1. Serverzertifkat an den Client
  3. Clientauthentifizierung und Schlüsselaustausch
    1. Clientzertifikat
    2. Pre master secret wird an den Server geschickt
  4. Beendigung
    • Umstellung auf die ausgehandelten Sicherheitsressourcen

Server- und Clientauthentifizierung

715px-SSL_handshake_with_two_way_authentication_with_certificates.svg.png
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
rightnun kann mit der Datenübertragung begonnen werden

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
Der Browser leitet Warnungen an den Benutzer weiter.
pic_6312_1.gif

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.
right 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

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?
  1. 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
  2. Neue Sitzung
    • Client schickt beim ClientHello die alte Session ID mit allen zusätzlichen Parametern mit
    • Server schickt die
      • alte Session ID zurück right Session kann wieder aufgenommen werden (verkürzter Handshake)
      • neue Session ID right 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
      sslResumption.gif
  • Unterschiede zum normalenHandshake
    • plus Client und Server erzeugen kein Master Secret
    • plus weniger Roundtrips
    • Client
      • minus baut sich einen Session Cache auf (geringer Aufwand)
      • plusspart 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
      • minusAufbau eines Session Caches (hoher Aufwand)
        • Speicher (50-100 Byte je Session)
        • CPU Zeit um den Cache auszulesen
        • Synchronisation der Zugriffe aus verschiedenen Prozessen/Threads
      • plusspart sich
        • Entschlüsseln des pre_master_secret mit den geheimen Schlüssel des Masters (rechenintensiv)
        • Überprüfen der Signatur der CA bei einem Clientzertifikat
  • 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 Antwort HTTP/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'

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
  • rightVergleich 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

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

 

Quellen

Abonniere den Newsletter (+ pdf Päckchen)

Beiträge-Archiv

Sourcecode

Neuste Kommentare