Protokol SSL vytvořila firma Netscape. Konkurenční firma Microsoft vytvořila obdobný protokol PCT. Oba protokoly jsou si vzájemně natolik podobné, že mnohému software nečiní žádných potíží podporovat oba dva protokoly současně. V této publikaci se budeme podrobně zabývat protokolem SSL verze 3.
Naším cílem není popisovat konfiguraci klientů a serverů podporujících SSL. Nejlepší takovéto návody lze nalézt přímo na stránkách První certifikační autority http://www.ica.cz .
Protokol TCP/IP neřešil problematiku zabezpečení přenášených dat. Klasický model protokolu TCP/IP v sobě nezahrnuje žádnou vrstvu, která by se touto problematikou zabývala:
Vrstva SSL (Secure Sockets Layer) dodatečně řešící zabezpečení přenášených dat je vložena mezi aplikační protokol a protokol TCP.
SSL se specializuje na zabezpečení přenosu dat mezi klientem a serverem:
Pro pochopení funkce SSL je třeba se na tuto vrstvu podívat podrobněji. SSL se skládá ze 4 dílčích protokolů:
Každá strana tedy udržuje dvakrát některé parametry komunikace ve svých datových strukturách. Jednou udržuje aktuální data používaná protokolem RLP a podruhé připravovaná data protokolem HP.
Klient se serverem pro komunikaci zřizují tzv. relaci (session), relace může zahrnovat jedno nebo více spojení (connection). Pro úplnost je třeba ještě dodat, že mezi dvěma počítači může být současně zřízeno i více relací.
Klient i server ve svých strukturách udržují následující informace:
V kapitole o HP si popišeme kdy si klient a server vyměňují svá náhodná čísla (ServerRandom a ClientRandom) a jak se stanovuje sdílené tajemství. Myšlenka pak spočívá v tom, že se vezme sdílené tajemství a obě náhodná čísla a z jejich kombinací se vypočítá kontrolní součet algorimem MD5 a algoritmem SHA. Vznikne tak špalek dat (key_block).
Pro zajímavost i přesná formulace podle normy:
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 kontrolního součtu serveru (server_write_MAC_secret), pak šifrovací klíč klienta (client_write_key), šifrovací klíč serveru 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 */
(norma pro popis SSL používá v hranatých závorkách
vyjádření délky v bajtech)
Kontrolní součet se nepočítá pouze z fragmentu (resp. komprimovaného fragmentu), ale fragment se pro výpočet kontrolního součtu sřetězí s tajemstvím pro výpočet kontrolního součtu (write_MAC_secret), které je utajované podobně jako jsou utajovány symetrické šifrovací klíče. Chtěl-li by útočník pozměnit obsah přenášeného fragmentu, pak k změněnému fragmentu není schopen vypočítat (a podvrhnout) kontrolní součet neboť nezná tajemství pro výpočet kontrolního součtu.
Záhlaví RLP se skládá ze tří položek.
Pro ilustraci jsem si pro předchozí obrázek MS Network Monitorem odchytil jeden paket protokolu HTTPS. Význam prvních pěti bajtů tvořících záhlaví protokolu RLP je vcelku evidentní. Zajímavé je něco úplně jiného, totiž jedná se o počáteční data, kterými klient obnovuje spojení se serverem. Jelikož klient se serverem ještě nejsou dohodnuti na žádném algoritmu pro kompresi, žádném algoritmu pro výpočet kontrolního součtu ani žádném šifrovacím algoritmu, tak RLP protokol nemůže provádět žádné zabezpečení, tj. komunikace běží nekomprimovaně, nešifrovaně a bez kontrolního součtu (česky řečeno: přenáší se "clear text"). Přesněnji řečeno: každý klient i server je nucen pro to, aby byl schopen navázat relaci, podporovat protokolovou svitu SSL_NULL_WITH_NULL_NULL ("žádné šifrování a žádný kontrolní součet"), rovněž musí podporovat komunikaci bez komprese.
V kapitole o HP si právě na tomto úvodním nešifrovaném dialogu protokol HP rozebereme. Vřele doporučuji všem zájemcům o pochopení SSL obdobný postup. Pro úplnost jen dodávám, že je třeba odříznout záhlaví linkové vrstvy, IP vrstvy i TCP vrstvy. V následujícím rámu je pak zobrazen původní paket z MS Network Monitoru. Spojení jsem navazoval s https://cert.ica.cz:4433. Před tímto TCP paketem musely předcházet ještě tři "nedatové" pakety, kterými protokol TCP sám navazuje spojení, ale to je problém spíše do kapitoly o protokolu TCP.
Úplný výpis prvního datového TCP paketu nesoucí data z předchozího obrázku
z MS Network Monitoru je:
|
660 21.325 P39AAP DEC 2171A4 TCP .AP..., len: 84, seq: 145165779-145165862, ack: 377664001, win: P39AAP cert.ica.cz IP + FRAME: Base frame properties
00000: 00 00 F8 21 71 A4 00 20 AF FA 25 89 08 00 45 00
...!q.. ..%...E.
|
Slovně bychom mohli zprávu Change cipher specification vyjádřit jako "změna šifrovacího klíče". Jen je třeba dodat, že tuto změnu provádí klient a server na sobě nezávisle, tj. jedna strana provede změnu a druhá třeba až za okamžik - za svou zprávou Change cipher specification.
TCP paket může obsahovat zprávu Change cipher specification uprostřed, tj. část RLP-fragmentu předcházející tuto zprávu je šifrována jinak než část RLP-fragmentu za touto zprávou.
Na obrázku je použito slovo svita. Používám jej více méně proto, že
se mi toto slovo líbí, i když protokolová svita specifikuje pouze algoritmus
použitý pro symetrickou šifru a algoritmus pro výpočet kontrolního součtu.
Struktura HP paketu připomíná RLP paket. V záhlaví jsou jakoby stejné informace. Rozdíl je mj. v tom, že HP paket už může být šifrován i se svým záhlavím.
Na předchozím obrázku je v paketu RLP uložena zpráva typu ClientHello
o délce 4B16. Nyní nám půjde o objasnění jednotlivých typů zpráv.
Poté si ztaženou stránku prohlížíme na obrazovce. Během prohlížení není navázáno žádné spojení - není ani jasné, zda-li budeme další informace požadovat z téhož nebo jiného HTTPS serveru. V případě, že požadujeme další stránku z téhož serveru, pak se pro ztažení nových objektů navazují nová TCP spojení a SSL tentokráte relaci obnovuje. O tom, zda-li bude relace obnovována rozhoduje nastavení klienta (obnovuje se zpravidla pokud mezi tím nebyl klientův program ukončen a znovu nastartován - to lze však prvděpodobně i změnit v konfiguraci klienta).
Při obnovování spojení klient odešle serveru zprávu ClientHello. Zpráva ClientHello obsahuje náhodné číslo ClinetRandom vstupující do výpočtu sdíleného tajemství. Zejména však zpráva ClinetHello obsahuje identifikátor obnovované relace. Dále zpráva ClientHello obsahuje seznam kryptografických algoritmů podporovaných klientem.
Server odpovídá zprávou ServerHello obsahující náhodné číslo ServerHello vstupující též do výpočtu sdíleného tajemství. Zpráva ServerHello obsahuje opět identifikátor obnovované relace a zejména kryprografické algoritmy, které si server vybral z těch, které klient podporuje. V případě, že server zamítne obnovit relaci či si nevybere z nabízených kryptografických algoritmů, pak server neodpoví zprávou ServerHello, ale protokolem Alert a uzavře TCP-spojení.
V případě, že server spojení neuzavře odešle protokolem Change cipher specification informaci, že "přešel na nové šifrovací klíče" a pošle zprávu Finished obsahující kontrolní součet ze všech zpráv od zprávy ClinetHello. Klient už jen pošle potvrzující zprávu Change cipher specification a Finished, kterými výměnu zpráv potvrdí. Dále již běží přenos vlastních aplikačních dat, který je šifrován. Každý RLP fragment obsahuje též kontrolní součet zabezpečující integritu přenášených dat (už zprávy Finished byly šifrovány).
Klient a server si vyměňují zprávy protokolu HP jak je znázorněno na následujícím obrázku:
Ne všechny zprávy jsou zprávy protokolu HP. V určitém okamžku oba partneři
vydávají zprávu Change cipher specification - "přejdi na nový šifrovací
klíč", která není zprávou protokolu HP, ale zprávou samostatného protokolu
Change cipher specification.
V kapitole o protokolu RLP jsme uvedeli příklad RLP paketu, který v sobě nesl zprávu ClinetHello. Z tohoto příkladu odřízneme záhlaví protokolů IP, TCP i záhlaví fragmentu RLP a získáme:
03 00 34 F3 C2 D1 1E AD 65 2B 7A 2F 95 A5 F0 68 AA 8E 55
F8 53 B3 B3 AC
C7 9E E9 0C B6 5C 62 A8 BE 9F 20 03 99 14 66 7F DE 5A 47 10
19 F6 47 C7
4D 15 6A 4A 43 3A BA B1 65 82 AC 98 52 68 7D 06 EE 2D E1
00 04 00 03 00
06 01 00
Na počátku jsou první dva bajty určující verzi: 03 00.
Následuje 32 bajtů náhodného čísla tvořeného 4B vyjadřujících datum a čas plus 28 B z generátoru náhodných čísel: 34 F3 C2 D1 1E AD 65 2B 7A 2F 95 A5 F0 68 AA 8E 55 F8 53 B3 B3 AC C7 9E E9 0C B6 5C 62 A8 BE 9F
První bajt Session ID specifikuje délku, následující bajty pak identifikátor relace: 2016=3210 03 99 14 66 7F DE 5A 47 10 19 F6 47 C7 4D 15 6A 4A 43 3A BA B1 65 82 AC 98 52 68 7D 06 EE 2D E1
Pole protokolových svit je uvozeno dvojbajtovou délkou, za kterým následují jednotlivé dvojice bajtů specifikující šifrovací protokol a protokol pro výpočet kontrolního součtu: 00 04 00 03 00 06. Z následující tabulky pak zjistíme, že klient podporuje dvě svity (4 bajty): SSL_RSA_EXPORT_WITH_RC4_40_MD5 a SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5. Tj. autentizaci pomocí RSA, šifrovací protokoly RC4 nebo RC2 s exportními omezeními na délku klíče 40 bitů a kontrolní součet bude počítán podle algoritmu MD5.
Pole podporovaných kompresních metod je uvozeno 1B délky následovaným
jednobajtovými identifikacemi jednotlivých kompresních protokolů :
01 00 (tj. bez komprese)
| CipherSuite SSL_NULL_WITH_NULL_NULL
= 00 00
(předchozí svita je používána zejména na počátku komunikace) CipherSuite SSL_RSA_WITH_NULL_MD5 = 00 01 CipherSuite SSL_RSA_WITH_NULL_SHA = 00 02 CipherSuite SSL_RSA_EXPORT_WITH_RC4_40_MD5 = 00 03 CipherSuite SSL_RSA_WITH_RC4_128_MD5 = 00 04 CipherSuite SSL_RSA_WITH_RC4_128_SHA = 00 05 CipherSuite SSL_RSA_EXPORT_WITH_RC2_CBC_40_MD5 = 00 06 CipherSuite SSL_RSA_WITH_IDEA_CBC_SHA = 00 07 CipherSuite SSL_RSA_EXPORT_WITH_DES40_CBC_SHA = 00 08 CipherSuite SSL_RSA_WITH_DES_CBC_SHA = 00 09 CipherSuite SSL_RSA_WITH_3DES_EDE_CBC_SHA = 00 0A CipherSuite SSL_DH_DSS_EXPORT_WITH_DES40_CBC_SHA = 00 0B CipherSuite SSL_DH_DSS_WITH_DES_CBC_SHA = 00 0C CipherSuite SSL_DH_DSS_WITH_3DES_EDE_CBC_SHA = 00 0D CipherSuite SSL_DH_RSA_EXPORT_WITH_DES40_CBC_SHA = 00 0E CipherSuite SSL_DH_RSA_WITH_DES_CBC_SHA = 00 0F CipherSuite SSL_DH_RSA_WITH_3DES_EDE_CBC_SHA = 00 10 CipherSuite SSL_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA = 00 11 CipherSuite SSL_DHE_DSS_WITH_DES_CBC_SHA = 00 12 CipherSuite SSL_DHE_DSS_WITH_3DES_EDE_CBC_SHA = 00 13 CipherSuite SSL_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA = 00 14 CipherSuite SSL_DHE_RSA_WITH_DES_CBC_SHA = 00 15 CipherSuite SSL_DHE_RSA_WITH_3DES_EDE_CBC_SHA = 00 16 CipherSuite SSL_DH_anon_EXPORT_WITH_RC4_40_MD5 = 00 17 CipherSuite SSL_DH_anon_WITH_RC4_128_MD5 = 00 18 CipherSuite SSL_DH_anon_EXPORT_WITH_DES40_CBC_SHA = 00 19 CipherSuite SSL_DH_anon_WITH_DES_CBC_SHA = 00 1A CipherSuite SSL_DH_anon_WITH_3DES_EDE_CBC_SHA = 00 1B CipherSuite SSL_FORTEZZA_KEA_WITH_NULL_SHA = 00 1C CipherSuite SSL_FORTEZZA_KEA_WITH_FORTEZZA_CBC_SHA = 00 1D CipherSuite SSL_FORTEZZA_KEA_WITH_RC4_128_SHA = 00 1E |
Pro ilustraci si Network monitorem opět odchytíme odpoveď serveru klientovi:
| + FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol IP: ID = 0x9D71; Proto = TCP; Len: 119 IP: Version = 4 (0x4) IP: Header Length = 20 (0x14) + IP: Service Type = 0 (0x0) IP: Total Length = 119 (0x77) IP: Identification = 40305 (0x9D71) + IP: Flags Summary = 0 (0x0) IP: Fragment Offset = 0 (0x0) bytes IP: Time to Live = 60 (0x3C) IP: Protocol = TCP - Transmission Control IP: Checksum = 0x8A53 IP: Source Address = 194.149.104.203 IP: Destination Address = 194.149.104.198 IP: Data: Number of data bytes remaining = 99 (0x0063) TCP: .AP..., len: 79, seq: 377664001-377664079, ack: 145165863, win:33580,... TCP: Source Port = 0x1151 TCP: Destination Port = 0x05B2 TCP: Sequence Number = 377664001 (0x1682B201) TCP: Acknowledgement Number = 145165863 (0x8A70E27) TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 (0x0000) + TCP: Flags = 0x18 : .AP... TCP: Window = 33580 (0x832C) TCP: Checksum = 0xC423 TCP: Urgent Pointer = 0 (0x0) TCP: Data: Number of data bytes remaining = 79 (0x004F) 00000: 00 20 AF FA 25 89 00 00 F8 21 71 A4 08 00 45 00
. ..%....!q...E.
|
Po odříznutí záhlaví IP a TCP získáme:
16 03 00 00 4A 02 00 00 46 03 00 34 F3 D0 18 4C 49 D9 E1 07 A6 C4 0D 8D A1 BD 09 53 C7 1B B8 51 8F E9 56 2B 7A FF 41 D9 E8 13 10 20 03 99 14 66 7F DE 5A 47 10 19 F6 47 C7 4D 15 6A 4A 43 3A BA B1 65 82 AC 98 52 68 7D 06 EE 2D E1 00 03 00
Záhlaví RLP fragmentu je 16 03 00 00 4A. Kde 16 specifikuje Handsake Protocol, 03 00 určuje verzi 3.0 a 4A16=7410vyjadřuje délku RLP fragmentu.
Záhlaví HP protokolu je 02 00 00 46. Kde 02 specifikuje zprávu ServerHello a 00004616=7010 vyjadřuje délku zprávy.
Verze záhlaví protokolu HP je opět 03 00.
Náhodné číslo (ServerRandom) je dlouhé 32 bajtů: 34 F3 D0 18 4C 49 D9 E1 07 A6 C4 0D 8D A1 BD 09 53 C7 1B B8 51 8F E9 56 2B 7A FF 41 D9 E8 13 10.
Identifikátor relace začíná jedním bajtem specifikujícím délku identifikátoru (2016=3210) následovaným vlastním identifikátorem relace: 20 03 99 14 66 7F DE 5A 47 10 19 F6 47 C7 4D 15 6A 4A 43 3A BA B1 65 82 AC 98 52 68 7D 06 EE 2D E1.
Pak následuje serverem vybraná protokolová svita (jedna z těch které nabízí klient - v případě, že by si server nevybral, pak neodpoví zprávou ServerHello, ale Alert Protokolem a následuje ukončení spojení). V našem případě server zvolil svitu 00 03, tj. podle tabulky SSL_RSA_EXPORT_WITH_RC4_40_MD5.
Poslední bajt obsahuje serverem zvolený komprimační algoritmus. V tomto
případě volba 00 signalizuje, že komprese nebude použita.
Zpráva Finished obsahuje kontrolní součet algorimem MD5 následovaný kontrolním součet algoritmem SHA z řetězce skládajícího se mj. ze sdíleného tajemství a obsahu všech zpráv od zprávy ClientHello. Jelikož sdílené tajemství zná pouze klient a server, tak je velice obtížné útočníkovi do obnovování spojení vložit nějaká nepatřičná data. Jedná se již o šifrovaná data, tedy do nich nevidíme network monitorem.
Vraťme se k našemu příkladu. Server vrací v jednom TCP paketu
change cipher specification a zprávu Finished:
| + FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol IP: ID = 0x9D73; Proto = TCP; Len: 107 IP: Version = 4 (0x4) IP: Header Length = 20 (0x14) + IP: Service Type = 0 (0x0) IP: Total Length = 107 (0x6B) IP: Identification = 40307 (0x9D73) + IP: Flags Summary = 0 (0x0) IP: Fragment Offset = 0 (0x0) bytes IP: Time to Live = 60 (0x3C) IP: Protocol = TCP - Transmission Control IP: Checksum = 0x8A5D IP: Source Address = 194.149.104.203 IP: Destination Address = 194.149.104.198 IP: Data: Number of data bytes remaining = 87 (0x0057) TCP: .AP..., len: 67, seq: 377664080-377664146, ack: 145165863, win:33580,... TCP: Source Port = 0x1151 TCP: Destination Port = 0x05B2 TCP: Sequence Number = 377664080 (0x1682B250) TCP: Acknowledgement Number = 145165863 (0x8A70E27) TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 (0x0000) + TCP: Flags = 0x18 : .AP... TCP: Window = 33580 (0x832C) TCP: Checksum = 0xBF40 TCP: Urgent Pointer = 0 (0x0) TCP: Data: Number of data bytes remaining = 67 (0x0043) 00000: 00 20 AF FA 25 89 00 00 F8 21 71 A4 08 00 45 00
. ..%....!q...E.
|
14 03 00 00 01 01 je change cipher specification.
Ze záhlaví RLP fragmentu předcházející vlastní zprávu Finished jsme
schopni poznat pouze, že se jedná o HP protokol (16) verzi (03 00) a délku,
která je šetnáctkově 0038. Dále už je vše šifrováno:
16 03 00 00 38 F5 69 2F 21 94 07 87 5A
9E 63 EB 56 01 02 91 DD DB 78 42 31 91 BA 3F 05 80 71 D3 86 9D E9 BB 79
06 5F 75 36 27 3D 04 A0 B7 93 D5 64 56 FC D4 80 B0 52 E2 C2 7A E4 4E 8D
Přesto stojí za to se nad touto zašifrovanou zprávou ještě zamyslet. RLP fragment se zprávou finished má strukturu:
Ze zprávy ServerHello jsme zjistili, že server zvolil svitu SSL_RSA_EXPORT_WITH_RC4_40_MD5, tj. RLP fragment obsahuje na konci ještě kontrolní součet algoritmem MD5 (16 bajtů) a výplň. Takže aniž bychom viděli do přenášených dat tak ve zbylých tj. šifrovaných bajtech (po odříznutí i RLP záhlaví): F5 69 2F 21 94 07 87 5A 9E 63 EB 56 01 02 91 DD DB 78 42 31 91 BA 3F 05 80 71 D3 86 9D E9 BB 79 06 5F 75 36 27 3D 04 A0 B7 93 D5 64 56 FC D4 80 B0 52 E2 C2 7A E4 4E 8D
Prvních16+20 bajtů (F5 69 2F 21 94 07 87 5A 9E 63 EB 56 01 02 91 DD DB 78 42 31 91 BA 3F 05 80 71 D3 86 9D E9 BB 79 06 5F 75 36) musí být vlastní zpráva Finished, dalších 16 bajtů (27 3D 04 A0 B7 93 D5 64 56 FC D4 80 B0 52 E2 C2) kontrolní součet z RLP fragmentu a zbytek 7A E4 4E 8D může být jen výplň.(Ja to nevím, protože jsem to nedešifroval, ale jak by to bylo jinak?)
Následuje odpověď klienta ve dvou TCP paketech:
| + FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol IP: ID = 0x4430; Proto = TCP; Len: 46 IP: Version = 4 (0x4) IP: Header Length = 20 (0x14) + IP: Service Type = 0 (0x0) IP: Total Length = 46 (0x2E) IP: Identification = 17456 (0x4430) + IP: Flags Summary = 2 (0x2) IP: Fragment Offset = 0 (0x0) bytes IP: Time to Live = 128 (0x80) IP: Protocol = TCP - Transmission Control IP: Checksum = 0x5FDD IP: Source Address = 194.149.104.198 IP: Destination Address = 194.149.104.203 IP: Data: Number of data bytes remaining = 26 (0x001A) TCP: .AP..., len: 6, seq: 145165863-145165868, ack: 377664147, win: 8614, ... TCP: Source Port = 0x05B2 TCP: Destination Port = 0x1151 TCP: Sequence Number = 145165863 (0x8A70E27) TCP: Acknowledgement Number = 377664147 (0x1682B293) TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 (0x0000) + TCP: Flags = 0x18 : .AP... TCP: Window = 8614 (0x21A6) TCP: Checksum = 0x2B79 TCP: Urgent Pointer = 0 (0x0) TCP: Data: Number of data bytes remaining = 6 (0x0006) 00000: 00 00 F8 21 71 A4 00 20 AF FA 25 89 08 00 45 00
...!q.. ..%...E.
|
Následující TCP paket obsahuje zprávu Finished bezprostředně již následovanou
šifrovanými aplikačními daty. Aplikační data jsou vyznačeně kurzivou:
| + FRAME: Base frame properties
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol IP: ID = 0x4530; Proto = TCP; Len: 438 IP: Version = 4 (0x4) IP: Header Length = 20 (0x14) + IP: Service Type = 0 (0x0) IP: Total Length = 438 (0x1B6) IP: Identification = 17712 (0x4530) + IP: Flags Summary = 2 (0x2) IP: Fragment Offset = 0 (0x0) bytes IP: Time to Live = 128 (0x80) IP: Protocol = TCP - Transmission Control IP: Checksum = 0x5D55 IP: Source Address = 194.149.104.198 IP: Destination Address = 194.149.104.203 IP: Data: Number of data bytes remaining = 418 (0x01A2) TCP: .AP..., len: 398, seq: 145165869-145166266, ack: 377664147, win: 8614,... TCP: Destination Port = 0x1151 TCP: Sequence Number = 145165869 (0x8A70E2D) TCP: Acknowledgement Number = 377664147 (0x1682B293) TCP: Data Offset = 20 (0x14) TCP: Reserved = 0 (0x0000) + TCP: Flags = 0x18 : .AP... TCP: Window = 8614 (0x21A6) TCP: Checksum = 0x223D TCP: Urgent Pointer = 0 (0x0) TCP: Data: Number of data bytes remaining = 398 (0x018E) 00000: 00 00 F8 21 71 A4 00 20 AF FA 25 89 08 00 45 00
...!q.. ..%...E.
|
Aplikační data jsou uložena v RLP fragmentu na jeho počátku, za nimi následuje kontrolní součet a výplň.
Poučení: Takto zabezpečeným kanálem bychom nikdy neměli posílat např. údaje o kreditních kartách atp. Při elektronickém obchodování je protokol HTTPS určen pro vybírání zboží (procházení virtuálním obchodním domem); pro vlastní placení zboží by se pak použít protokol SET.
Poznámka: v předchozích ukázkách jsem odchytil pakety a vypsal.
Vypsal jsem pouze pakety nesoucí z hlediska protokolu TCP data, pakety
bez dat (bez TCP-přiznaku PUSH), které pouze potvrzují přijetí dat jsem
vynechal, takže při bližším zkoumání uvedených paketů zjistíte, že mohou
být přeskočeny některé sekvence ACK (byly potvrzeny vynechanými nedatovými
pakety).