Zřízení nové relace

Autentizace serveru se provádí vždy. Autentizace klienta se provádí pouze v případě, že server není anonymní.

Zprávy ClientHello a ServerHello mají stejný význam jako při obnovování spojení. Pouze zpráva ClientHello obsahuje nevyplněné identifikační číslo relace. Indentifikační číslo relace přiděluje až server ve zprávě ServerHello. Zprávy ClientHello a ServerHello obsahují náhodná číslo ClientRandom a ServerRandom vstupující do procesu výpočtu sdíleného tajemství. Dále klient nabídne podporované kryptografické algoritmy a server si ve zprávě SereverHello z nich vybere.

Server posílá klientovi svůj certifikát (resp. řetězec certifikátů až k root CA). Server může odeslat zprávu Cerificate, kterou žádá klienta o jeho certifikát. Nakonec server odešle prázdnou zprávou ServerHelloDone, kterou signalizuje klientu, že nyní je řada na něm, tj. očekává reakci klienta.

Klient v případě, že chce na server přistupovat neanonymně odesílá serveru svůj certifikát  (resp. řetězec certifikátů). Dále následuje zcela klíčová zpráva ClientKeyExchange. Tato zpráva obsahuje veřejným klíčem z certifikátu serveru šifovaný tzv. PreMasterSecret, ze kterého se počítá master secret (sdílené tajemství). Tím se také provede autentizace serveru. Podvržený server, který k veřejnému klíči nevlastní odpovídající soukromý klíč nemůže získat správné PreMasterSecret (nedokáže jej dešifrovat).

Při zjednodušeném výkladu pricipu SSL se často říká, že SSL používá pro šifrování zpráv symetrickou šifru. Šifrovací klíč pro symetrickou šifru generuje klient. Proto aby symetrický šifrovací klíč mohl klient bezpečně předat serveru po nezabezpečeném Internetu, tak jej šifruje veřejným klíčem z certifikátu serveru, tj. asymetrickou širou, a odešle serveru.

Skutečnost je ale taková, že takto vznikne pouze PreMasterSecret, ze kterého se spočítá master sekret. Z master secret, ClientRandom a ServerRandom se spočte špalek dat, ze kterého se teprve odsekávají  šifrovací klíče.

Výpočet MasterSecret se provádí podle vzorce:

master_secret =
       MD5(PreMasterSecret + SHA('A' + PreMasterSecret +
           ClientRandom + ServerRandom)) +
       MD5(PreMasterSecret + SHA('BB' + PreMasterSecret +
           ClientRandom + ServerRandom)) +
       MD5(PreMasterSecret + SHA('CCC' + PreMasterSecret +
           ClientRandom + ServerRandom)

Po předání zprávy ClientKeyExchange  jak klient, tak server znají

• ClientRandom (ze zprávy ClientHello).
• ServerRandom (ze zprávy ServerHello)
• master_secret (ze zprávy ClientKeyExchange)

 key_block =
       MD5(master_secret + SHA(`A' + master_secret +
                               ServerRandom + ClientRandom)) +
       MD5(master_secret + SHA(`BB' + master_secret +
                               ServerRandom +  ClientRandom)) +
       MD5(master_secret + SHA(`CCC' + master_secret +
                               ServerRandom + ClientRandom)) + [...];
 

Ze špalku dat se nejprve odseknou data tvořící tajemství pro výpočet kontrolního součtu klienta (client_write_MAC_secret), pak data tvořící tajemství pro výpočet kokntrolního součtu serveru (server_write_MAC_secret), pak šifrovací klíč klienta (client_write_key), šifrovací klíč serveru (server_write_key) a nakonec inicializační vektory.

      client_write_MAC_secret[CipherSpec.hash_size]
     server_write_MAC_secret[CipherSpec.hash_size]
     client_write_key[CipherSpec.key_material]
     server_write_key[CipherSpec.key_material]
     client_write_IV[CipherSpec.IV_size] /* non-export ciphers */
     server_write_IV[CipherSpec.IV_size] /* non-export ciphers */

Odsekávání ze špalku dat je znázorněno na následujcícím obrázku:

Takže nyní jak klient, tak i server vzájemně znají své symetrické šifrovací klíče i tajemství pro výpočet kontrolního součtu. Jak klient tak server používají každý své (tj. každý jiné) šifrovací klíče i tajemství pro výpočet kontrolního součtu.

V případě, že klient přistupuje neanonymně na server, pak musí prokázat svou totožnost, tj. identifkovat se. Klient prokazuje svou totožnost ve zprávě CertificateVerify. Nejprve vytvoří řetězec skládající se mj. z master_secret a z obsahu všech zpráv od zprávy ClientHello. Tento řetězec je schopen vytvořit jen klient a server (jen ti znají sdílené tajemství). Klient ve zprávě CertificateVerify odesílá elektronický podpis z tohoto řetězce. Server si pak ověří totožnost klienta na základě ověření (verifikace) tohoto elektronického podpisu.

Závěr je pak již zcela obdobný jako u obnovování spojení, tj. protokolem Change cipher specification se signalizuje "přechod na nové šifrovací klíče" a zpráva Finished navazování spojení končí. Poté už může běžet zabezpečený přenos aplikačních dat.

Následujcí obrázek schématicky vyjadřuje výměnu jednotlivých zpráv mezi klientem a serverem v případě, že server se autentizuje pomocí certifikátu.  Nepovinné zprávy CertificateRequest, Certificate (od klienta) a zpráva CertificateVerify sloužící k autentizaci klienta jsou uvedeny v hranatých závorkách.

Nyní si rozebereme jednotlivé zprávy podrobněji. Pro ilustraci použijeme zprávy, které jsem opět odchytil na LAN pomocí MS Network Monitoru (nebudu však uvádět již kompletní výpis z MS Network Monitoru).

ClientHello

Nebudeme se zabývat prvními 2B, tj. záhlavím protokolu RLP verze 2. (25 šestnáctkově vyjadřuje délku zprávy).

00000030                    80 25 01 03 00 00 0C 00 00 00       .%........
00000040  10 02 00 80 04 00 80 00 00 03 00 00 06 90 9F A1 ................
00000050  01 CC FA 9E CC 86 C0 DB AF DB 3F EE 8F          ..........?..

Zpráva ClientHello verze 2 má strukturu:

• Typ zprávy, zprávě ClientHello odpovídá 01.
• Verze 03 00.
• 2B délka pole svit: 00 0C (desítkově 12).
• 2B délka identifikátoru relace 00 00. Tato zpráva se pokouší zřídit novou relaci - nenavazuje na žádnou předchozí relaci, proto identifikátor neposílá. Volba identifikátoru relace je výsostným právem serveru.
• 2B délka náhodného čísla generovaná klientem (ClientRandom) - pro verzi 3.0 musí být alespoň 16B.
• Podporované svity protokolů. Verze 2 používá ke specifikaci svity dlouhé 3B. Jelikož toto pole je dlouhé 12B, tak jsou specifikovány 4 svity: 02 00 80 | 04 00 80 | 00 00 03 a 00 00 06. Prakticky se jedná o dvě svity, které jsou nejprve specifikovány podle verze 2 a poté tytéž svity specifikované podle verze 3 (první bajt má hodnotu 00).
• Identifikátor relace (v našem příkladu není).
• ClientRandom: 90 9F A1 01 CC FA 9E CC 86 C0 DB AF DB 3F EE 8F

Zprávy ServerHello, Certificate, CertificateRequest a ServerHelloDone

• Zprávu Server Hello
• Zprávu Certificate.
• Neobsahuje zprávu CertificateRequest, protože server je  anonymní.
• Zprávu ServerHelloDone

Záhlaví RLP:
00000030                    16 03 00 02 4B

ServerHello:
                                           02 00 00 46 03       ....K...F.
00000040  00 34 F8 1D 68 B2 8F DE EB 72 3B E9 FD 94 AD B8 .4..h....r;.....
00000050  84 C3 7A AE C8 47 7B 89 1A 01 BB CA 3A 39 10 6F ..z..G{.....:9.o
00000060  1A 20 0B 79 5E 44 F4 3E 8F A5 61 75 29 19 52 3C ...y^D.>..au).R<
00000070  FA 01 61 31 8C 3F 2F 3C 48 0F 87 C9 1E 31 B7 19 ..a1.?/<H....1..
00000080  7D 4A 00 03 00

Certificate:
                         0B 00 01 F9 00 01 F6 00 01 F3 30 }J.............0
00000090  82 01 EF 30 82 01 58 A0 03 02 01 02 02 01 0B 30 ...0..X........0
000000A0  0D 06 09 2A 86 48 86 F7 0D 01 01 04 05 00 30 45 ...*.H........0E
000000B0  31 0B 30 09 06 03 55 04 06 13 02 43 5A 31 11 30 1.0...U....CZ1.0
000000C0  0F 06 03 55 04 0A 13 08 50 56 54 20 61 2E 73 2E ...U....PVT.a.s.
000000D0  31 23 30 21 06 03 55 04 03 13 1A 43 65 72 74 69 1#0!..U....Certi
000000E0  66 69 6B 61 63 6E 69 20 61 75 74 6F 72 69 74 61 fikacni.autorita
000000F0  20 49 2E 43 41 30 1E 17 0D 39 37 31 32 31 36 31 .I.CA0...9712161
00000100  30 30 35 35 32 5A 17 0D 39 38 30 36 31 37 31 30 00552Z..98061710
00000110  30 35 35 32 5A 30 45 31 0B 30 09 06 03 55 04 06 0552Z0E1.0...U..
00000120  13 02 43 5A 31 11 30 0F 06 03 55 04 0A 13 08 50 ..CZ1.0...U....P
00000130  56 54 20 61 2E 73 2E 31 0D 30 0B 06 03 55 04 0B VT.a.s.1.0...U..
00000140  13 04 49 2E 43 41 31 14 30 12 06 03 55 04 03 13 ..I.CA1.0...U...
00000150  0B 63 65 72 74 2E 69 63 61 2E 63 7A 30 5A 30 0D .cert.ica.cz0Z0.
00000160  06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 49 00 ..*.H.........I.
00000170  30 46 02 41 00 A8 0E E9 04 32 FF 71 40 93 F1 4F 0F.A.....2.q@..O
00000180  D1 95 42 FD 97 8A 58 EA 27 66 47 63 1C BC FD 93 ..B...X.'fGc....
00000190  28 54 F5 A4 C6 11 FB B5 EA E4 B6 79 EB 8E 55 2C (T.........y..U,
000001A0  78 0F 3D 3B FC 3F 96 53 AF 4E F2 A1 4C 6F 5C 3C x.=;.?.S.N..Lo\<
000001B0  6C 8E C7 F2 A9 02 01 03 A3 35 30 33 30 11 06 03 l........5030...
000001C0  55 1D 23 04 0A 16 08 49 43 41 4B 45 59 2E 31 30 U.#....ICAKEY.10
000001D0  1E 06 09 60 86 48 01 86 F8 42 01 0D 04 11 16 0F ...`.H...B......
000001E0  57 57 57 20 73 65 72 76 65 72 20 49 2E 43 41 30 WWW.server.I.CA0
000001F0  0D 06 09 2A 86 48 86 F7 0D 01 01 04 05 00 03 81 ...*.H..........
00000200  81 00 26 C5 AA 60 9E 19 A9 70 AF E3 BC 62 09 D2 ..&..`...p...b..
00000210  96 93 21 B0 EF 0B 98 3A 43 62 7C 3F 24 63 45 9D ..!....:Cb|?$cE.
00000220  1E 22 C5 27 C8 73 79 7F 80 3A 0A E2 EA 02 F3 F8 .".'.sy.:......
00000230  FE 30 EC 8F 22 CD E1 43 23 48 3E 13 10 69 88 34 .0.."..C#H>..i.4
00000240  BA 03 65 5D AA E5 C8 62 1B 8C AA 24 A4 6D 6C 4B ..e]...b...$.mlK
00000250  C2 51 BE 9A B0 70 FE 8A 5C 29 F3 DF 50 BF 44 51 .Q...p..\)..P.DQ
00000260  B9 46 56 64 D0 1E 34 88 7A 86 74 48 54 F1 87 E6 .FVd..4.z.tHT...
00000270  54 15 D2 05 55 0E 36 2E 2E B8 44 03 CE 0D 11 BE T...U.6...D.....
00000280  6E 2A

ServerHelloDone:
                0E 00 00 00                               n*....
 

ServerHello

Kde záhlaví protokolu HP je tvořeno typem zprávy (02=ServerHello) a délkou zprávy protokolu HP (000046₁₆)
Dále následuje vlastní zpráva ServerHello:

• Verze: 03 00
• ServerRandom: 34 F8 1D 68 B2 8F DE EB 72 3B E9 FD 94 AD B8 84 C3 7A AE C8 47 7B 89 1A 01 BB CA 3A 39 10 6F 1A
• SessionID: 20 (délka 20₁₆=32₁₀) 0B 79 5E 44 F4 3E 8F A5 61 75 29 19 52 3C FA 01 61 31 8C 3F 2F 3C 48 0F 87 C9 1E 31 B7 19 7D 4A
• Zvolená svita: 00 03 (tj. SSL_RSA_EXPORT_WITH_RC4_40_MD5)
• Zvolený kompresní algoritmus: 00 (tj. bez komprese).

Certificate

0B 00 01 F9

Zpráva Certificáte obecně neobsahuje jeden certifikát, ale řetězec certifikátů až k root certifikační autoritě. Dále tedy následuje tříbajtová délka tohoto řetězce certifikátů. Každý certifikát v tomto řetězci opět začíná tříbajtovou délkou certifikátu. Jelikož náš příklad obsahuje pouze jeden certifikát, tak před ním je délka jakoby zdvojená:

00 01 F6 (délka řetězce certifikátů) 00 01 F3 (délka certifikátu). Lépe řečeno, když si k těmto dvěma délkám přimyslíme ještě délku ze záhlaví HP paketu, pak je délka ztrojená.

Vlastní certifikát je v PEM formátu:
                                             30
82 01 EF 30 82 01 58 A0 03 02 01 02 02 01 0B 30
0D 06 09 2A 86 48 86 F7 0D 01 01 04 05 00 30 45
31 0B 30 09 06 03 55 04 06 13 02 43 5A 31 11 30
0F 06 03 55 04 0A 13 08 50 56 54 20 61 2E 73 2E
31 23 30 21 06 03 55 04 03 13 1A 43 65 72 74 69
66 69 6B 61 63 6E 69 20 61 75 74 6F 72 69 74 61
20 49 2E 43 41 30 1E 17 0D 39 37 31 32 31 36 31
30 30 35 35 32 5A 17 0D 39 38 30 36 31 37 31 30
30 35 35 32 5A 30 45 31 0B 30 09 06 03 55 04 06
13 02 43 5A 31 11 30 0F 06 03 55 04 0A 13 08 50
56 54 20 61 2E 73 2E 31 0D 30 0B 06 03 55 04 0B
13 04 49 2E 43 41 31 14 30 12 06 03 55 04 03 13
0B 63 65 72 74 2E 69 63 61 2E 63 7A 30 5A 30 0D
06 09 2A 86 48 86 F7 0D 01 01 01 05 00 03 49 00
30 46 02 41 00 A8 0E E9 04 32 FF 71 40 93 F1 4F
D1 95 42 FD 97 8A 58 EA 27 66 47 63 1C BC FD 93
28 54 F5 A4 C6 11 FB B5 EA E4 B6 79 EB 8E 55 2C
78 0F 3D 3B FC 3F 96 53 AF 4E F2 A1 4C 6F 5C 3C
6C 8E C7 F2 A9 02 01 03 A3 35 30 33 30 11 06 03
55 1D 23 04 0A 16 08 49 43 41 4B 45 59 2E 31 30
1E 06 09 60 86 48 01 86 F8 42 01 0D 04 11 16 0F
57 57 57 20 73 65 72 76 65 72 20 49 2E 43 41 30
0D 06 09 2A 86 48 86 F7 0D 01 01 04 05 00 03 81
81 00 26 C5 AA 60 9E 19 A9 70 AF E3 BC 62 09 D2
96 93 21 B0 EF 0B 98 3A 43 62 7C 3F 24 63 45 9D
1E 22 C5 27 C8 73 79 7F 80 3A 0A E2 EA 02 F3 F8
FE 30 EC 8F 22 CD E1 43 23 48 3E 13 10 69 88 34
BA 03 65 5D AA E5 C8 62 1B 8C AA 24 A4 6D 6C 4B
C2 51 BE 9A B0 70 FE 8A 5C 29 F3 DF 50 BF 44 51
B9 46 56 64 D0 1E 34 88 7A 86 74 48 54 F1 87 E6
54 15 D2 05 55 0E 36 2E 2E B8 44 03 CE 0D 11 BE
6E 2A

Odskočíme-li si do kapitoly o certifiátech a certifikačních autoritách pak pomocí našeho konvertoru http://info.pvt.net/ssl.htm  si můžeme PEM formát certifikátu převést do textového tvaru:

SEQUENCE
    30 82 01 ef
  SEQUENCE
     30 82 01 58
   cont [ 0 ]
      a0 03
    INTEGER           :02
       02 01 02
   INTEGER           :0B
      02 01 0b
   SEQUENCE
      30 0d
    OBJECT            :md5withRSAEncryption
       06 09 2a 86 48 86 f7 0d 01 01 04
    NULL
       05 00
   SEQUENCE
      30 45
    SET
       31 0b
     SEQUENCE
        30 09
      OBJECT            :countryName
         06 03 55 04 06
      PRINTABLESTRING   :CZ
         13 02 43 5a
    SET
       31 11
     SEQUENCE
        30 0f
      OBJECT            :organizationName
         06 03 55 04 0a
      PRINTABLESTRING   :PVT a.s.
         13 08 50 56 54 20 61 2e 73 2e
    SET
       31 23
     SEQUENCE
        30 21
      OBJECT            :commonName
         06 03 55 04 03
      PRINTABLESTRING   :Certifikacni autorita I.CA
         13 1a 43 65 72 74 69 66 69 6b 61 63 6e 69 20 61 75 74 6f 72
         69 74 61 20 49 2e 43 41
   SEQUENCE
      30 1e
    UTCTIME           :971216100552Z
       17 0d 39 37 31 32 31 36 31 30 30 35 35 32 5a
    UTCTIME           :980617100552Z
       17 0d 39 38 30 36 31 37 31 30 30 35 35 32 5a
   SEQUENCE
      30 45
    SET
       31 0b
     SEQUENCE
        30 09
      OBJECT            :countryName
         06 03 55 04 06
      PRINTABLESTRING   :CZ
         13 02 43 5a
    SET
       31 11
     SEQUENCE
        30 0f
      OBJECT            :organizationName
         06 03 55 04 0a
      PRINTABLESTRING   :PVT a.s.
         13 08 50 56 54 20 61 2e 73 2e
    SET
       31 0d
     SEQUENCE
        30 0b
      OBJECT            :organizationalUnitName
         06 03 55 04 0b
      PRINTABLESTRING   :I.CA
         13 04 49 2e 43 41
    SET
       31 14
     SEQUENCE
        30 12
      OBJECT            :commonName
         06 03 55 04 03
      PRINTABLESTRING   :cert.ica.cz
         13 0b 63 65 72 74 2e 69 63 61 2e 63 7a
   SEQUENCE
      30 5a
    SEQUENCE
       30 0d
     OBJECT            :rsaEncryption
        06 09 2a 86 48 86 f7 0d 01 01 01
     NULL
        05 00
    BIT STRING
       03 49 00 30 46 02 41 00 a8 0e e9 04 32 ff 71 40 93 f1 4f d1
       95 42 fd 97 8a 58 ea 27 66 47 63 1c bc fd 93 28 54 f5 a4 c6
       11 fb b5 ea e4 b6 79 eb 8e 55 2c 78 0f 3d 3b fc 3f 96 53 af
       4e f2 a1 4c 6f 5c 3c 6c 8e c7 f2 a9 02 01 03
   cont [ 3 ]
      a3 35
    SEQUENCE
       30 33
     SEQUENCE
        30 11
      OBJECT            :X509v3 Authority Key Identifier
         06 03 55 1d 23
      OCTET STRING
         04 0a 16 08 49 43 41 4b 45 59 2e 31
     SEQUENCE
        30 1e
      OBJECT            :Netscape Comment
         06 09 60 86 48 01 86 f8 42 01 0d
      OCTET STRING
         04 11 16 0f 57 57 57 20 73 65 72 76 65 72 20 49 2e 43 41
  SEQUENCE
     30 0d
   OBJECT            :md5withRSAEncryption
      06 09 2a 86 48 86 f7 0d 01 01 04
   NULL
      05 00
  BIT STRING
     03 81 81 00 26 c5 aa 60 9e 19 a9 70 af e3 bc 62 09 d2 96 93
     21 b0 ef 0b 98 3a 43 62 7c 3f 24 63 45 9d 1e 22 c5 27 c8 73
     79 7f 80 3a 0a e2 ea 02 f3 f8 fe 30 ec 8f 22 cd e1 43 23 48
     3e 13 10 69 88 34 ba 03 65 5d aa e5 c8 62 1b 8c aa 24 a4 6d
     6c 4b c2 51 be 9a b0 70 fe 8a 5c 29 f3 df 50 bf 44 51 b9 46
     56 64 d0 1e 34 88 7a 86 74 48 54 f1 87 e6 54 15 d2 05 55 0e
     36 2e 2e b8 44 03 ce 0d 11 be 6e 2a
 

CertificateRequest

Tato zpráva se skládá ze dvou polí:

• Typy podporovaných certifikátů. Toto pole je uvozenou jednobajtovou délkou za kterou následují jednobajtové podporované typy certifikátů:
• 01 = rsa_sign
• 02 = dss_sign
• 03 = rsa_fixed_dh
• 04 = dss_fixed_dh
• 05 = rsa_ephemerical_dh
• 06 = dss_ephemerical_dh
• 20₁₆=14₁₀ = fortezza_dms
• Rozlišovací jména (Distinguished Name) certifikačních autorit, kterým server důvěřuje. Toto pole je uvozenou dvojbajtovou délkou. Rozlišovací jméno každé  uznávané CA je pak také předcházeno dvojbajtovou délkou. Rozlišovací jméno certifikační autority je rovněž v PEM formátu.

ServerHelloDone

• 0E (typ zprávy ServerHelloDone)
• 000000 (délka zprávy je nula - neobsahuje žádná data.

Zprávy Certificate, ClientKeyExchange a CertificateVerify

• ClientKeyExchange
• Change cipher specification, po které se přejde na zabezpečený provoz.
• Finished (již šifrováno)

ClientKeyExchange

00000030                    16 03 00 00 44 10 00 00 40 5A       ....D...@Z
00000040  E0 15 23 B7 24 70 0E 96 0A CB 28 F2 4D 27 13 D7 ..#.$p....(.M'..
00000050  F1 B5 BF 2A 40 A3 E7 EE 11 07 AB 14 90 5B AE AC ...*@........[..
00000060  79 7B 5E 59 C3 A1 11 15 5C 67 D3 35 32 97 B5 23 y{^Y....\g.52..#
00000070  96 8A 4D D6 A8 D3 7F A9 73 F7 6B 47 1B 75 1A    ..M....s.kG.u.

Vlastní zpráva ClientKeyExchange je uvedena záhlavím protokolu HP: 10 00 00 40, kde 10 specifikuje, že se jedná o zprávu ClientKeyExchange a 000040 délku této zprávy. Obsah zprávy je ve zbylých bajtech. Tato zpráva obsahuje veřejným klíčem serveru šifrovaný PreMasterSecret, ze kterého se počítá master_secret (sdílené tajemství).

Další TCP paket obsahuje dva RLP fragmenty:

• Zprávu ChangeCipherSpecification 14 03 00 00 01 01 jejíž struktru jsme již probraly u obnovování spojení.
• Zprávu Finished, jejíž strukturu jsme též probrali při obnovování spojení.

Server odpovídá zprávou ChangeCipherSpecification a rovněž přechází na zabezpečené spojení:

00000030                    14 03 00 00 01 01                   ......  

Server pak jen ukončuje dialog v protokolu HP zprávou Finished, jenž je již šifrována:

00000030                    16 03 00 00 38 1D 84 FA B4 5D       ....8....]
00000040  3A DF 1C D8 9E 73 4B FB 59 98 09 D6 F7 29 EA FE :....sK.Y....)..
00000050  95 BC 1B 61 3A 31 4C 4C 77 09 11 F5 27 D3 1A A4 ...a:1LLw...'...
00000060  85 FB 26 0F 04 EB 6F 34 50 D5 8E 80 1C 2B 78 B9 ..&...o4P....+x.
00000070  BE F7 90                                        ...

Ještě naposledy si všimneme, že i šifrované RLP fragmenty nemají šifrováno záhlaví. Klient pak bude pravděpodobně metodou GET požadovat data z HTTPS serveru. Data jsou však šifrována (kromě RLP-záhlaví), takže se o obsahu můžeme jen domnívat:

00000030                    17 03 00 01 02 CF CA 6F AC 07       .......o..
00000040  BD D2 D1 1F 13 92 B5 F4 81 90 F5 B2 7B C8 D0 08 ............{...
00000050  42 A7 D5 BC C5 65 29 38 92 95 C7 F7 10 79 A7 DC B....e)8.....y..
00000060  4F FC 39 C8 91 5C D3 7B 6C 84 18 C0 83 0D 07 0D O.9..\.{l.......
00000070  D8 7F C4 FC 4C 4C 7A 10 72 D0 84 AF 0B D6 90 49 ...LLz.r......I
00000080  0F 8F 0D BF 8F F0 19 61 F3 C2 60 E1 55 7E 80 F7 .......a..`.U~..
00000090  02 F3 81 F0 5C 63 A4 AB 68 B8 53 2F C7 0C 84 90 ....\c..h.S/....
000000A0  E3 7B 3C 50 79 1C 84 EF 8F E3 BC 5B 9D B5 0C B2 .{<Py......[....
000000B0  94 47 2F 22 D2 98 97 74 87 C9 F8 BF BF 13 6A B3 .G/"...t......j.
000000C0  F1 CB 81 B3 DA AA 28 08 EE 00 43 92 F2 17 1B E3 ......(...C.....
000000D0  4D DA EF 92 4B 39 85 6F 03 45 08 37 85 BF A2 E7 M...K9.o.E.7....
000000E0  1B 81 26 1A 43 C1 BA 43 8E D2 4F 1B CA E0 01 AE ..&.C..C..O.....
000000F0  4B E0 D3 1C AF 5D DA E7 26 7D 55 55 9F 5B AB 77 K....]..&}UU.[.w
00000100  A1 34 3E ED 62 F6 6D 60 80 95 6F 4F 3A 3F B6 D2 .4>.b.m`..oO:?..
00000110  6B 08 0F A6 13 6D A3 4D 40 1B D2 99 D5 CA 72 EB k....m.M@.....r.
00000120  0E 4E AB 09 E7 FA 7D FB 06 7B 3A 37 95 76 5F CA .N....}..{:7.v_.
00000130  01 D6 30 3B 38 2E AC BF B4 A5 A8 32 10          ..0;8......2.

Server pravděpodobně odpovídá "HTTP/1.0 200 OK" (opět pouze domněnka, protože data jsou šifrována):

00000030                    17 03 00 00 DD 4C C5 E8 60 A5       .....L..`.
00000040  A3 9A D3 CF 21 13 7B 69 A8 B0 87 6D BC 0B CD 07 ....!.{i...m....
00000050  79 76 67 E6 E7 C5 50 43 52 2D 78 3B 73 49 5B 3B yvg...PCR-x;sI[;
00000060  0C 0F EF 9D 2B 11 AD DC 7F 2C 79 64 7A 1F C1 8B ....+...,ydz...
00000070  75 2F 4A 6B AE 26 2C 86 9C 0D 14 70 76 64 1C 83 u/Jk.&,....pvd..
00000080  BC EC 64 D8 2F D6 AC 07 1A DA FE D3 89 87 34 36 ..d./.........46
00000090  D2 46 C8 41 57 13 25 77 0A 88 32 A1 78 DD D6 B8 .F.AW.%w..2.x...
000000A0  75 63 A2 9D 0A 0F 35 B0 4B 08 1A 03 C6 E2 EA 88 uc....5.K.......
000000B0  13 30 3F BC 16 45 23 0B 3E 77 50 3A 8F F5 C7 C3 .0?..E#.>wP:....
000000C0  3F 21 53 32 D9 FB 67 2E FD B0 14 6C 3F 7E 10 6D ?!S2..g....l?~.m
000000D0  4B 2E 44 17 5B 8F B7 8B D9 45 16 0D FD 88 01 03 K.D.[....E......
000000E0  05 7D BB A1 19 64 FD 32 1D EA 98 67 70 4A EB 38 .}...d.2...gpJ.8
000000F0  04 7C 10 1B 3E 1A 7F 13 10 9F 13 00 A8 05 FF 6B .|..>.........k
00000100  50 59 CD 8E 32 60 3C C5 B8 D6 77 37 65 A8 F6 CA PY..2`<...w7e...
00000110  05 5F 83 AD C7 4D 9F EC                         ._...M..
 
Kde z nešifrovaného záhlaví RLP fragmentu se dozvídáme, že se jedná o aplikační data (17), verzi 3.0 (0300) a délka fragmentu včetně kontrolního součtu a výplně je DD₁₆. Dále je obsah fragmentu šifrován.
 

Metoda CONNECT

Metoda CONNECT je dnes podporována převážnou většinou firewallů. I když tato metoda je rozšířením HTTP protokolu, pak jak z principu uvidíte, nic nebrání ji používat i pro jiné aplikační protokoly běžící přes SSL. Navíc pokud bychom používali např. TELNET přes SSL, pak není třeba provozovat žádná další speciální proxy na firewallu pro TELNET přes SSL - stačí použít proxy pro HTTPS. Jediné co je k tomu třeba je mít k dispozici software pro klienta i  server pro TELNET přes SSL, který rovněž podporuje metodu CONNECT. (Na takový software je nejlépe se optat u provozovatelů certifikačních autorit.)

Klient, který chce použít SSL a je za firewallem si nejprve nakonfiguruje ve svém klientovi IP-adresu nebo jméno firewallu -  tzv. Security Proxy (terminologie Netscape). Při přístupu skrze firewall nejprve klient bude navazovat TCP spojení s firewallem,aniž by aktivoval SSL. Takto otevřeným TCP kanálem klient odešle firewallu:

CONNECT server [port]
(implicitně  port 443)

Firewall otevře TCP spojení se serverem uvedeným v příkazu CONNECT na portu uvedeném jako poslední parametr. Nyní má firewall dvě spojení (dvě roury) jedno klient-firewall a druhé firewall-server. Nyní tyto dvě roury "navaří" na sebe, tj. binárně kopíruje vše co z jedné strany přišlo na druhou stranu. A tak klient již může začít se zprávou ClientHello navazovat SSL-relaci. Firewall mechanicky vše kopíruje, takže ani neví, že jim nějaká zpráva ClientHello  prošla.

Pochopitelně, že takováto proxy na firewallu nemůže provádět cache přenášených souborů - nevidí z jakých souborů se přenos skládá.

Rezervované porty serverů

443 - HTTPS (HTTP přes SSL)
465 - SSMTP (SMTP přes SSL)
563 - SNNTP (NNTP přes SSL)
636 - Secure LDAP (LDAP přes SSL)
995 - POP3 přes SSL.