Post by Reijo KorhonenTuossa olet oikeassa, että avaintenvaihto on raskaampi operaatio kuin
salaamattoman HTTP-yhteyden avaus. Mutta muuten sulla ei näköjään ole
pienintäkään käsitystä siitä, miten webbipalvelut toimivat.
Sanoisin että sinulla ei ole mitään käsitystä miten wrpppipalvelut
toimivatt, kun et ole huomannut, että esimerkiksi pankkipalveluja ei
tosiaankaan rakenneta http-yhteyden varaan. Joten kyllä noissa
yhteystavoissa on aika iso periaatteelinen ero, vaikka molempia
käytetäänkin ihan samalla selaimella, jossa ne näyttävät samalta.
Siis SSL/TLS yhteys on sessio siinä olet oikeassa, mutta myös pelkkä
TCP on sessio. Sitten HTTPS on HTTP over SSL, eli se käyttää ihan
normaalia HTTP:tä tuon avatun SSL yhteyden päällä. Ja HTTP on
lyhyesti "lähetä GET/POST pyyntö, odota vastausta, ja vastauksen
jälkeen voit pitää tuota yhteyttä auki keepalive-timeoutin verran
siltä varalta, josko sitä kohta tarvittaisiin uudestaan".
SSL ei webbisovelluksille käytännössä tarjoa mitään lisäapuja
webbisovellusten sessionhallintaan (verrattuna siis pelkkään
salaamattomaan HTTP:hen), oikeastaan ainoa mihin siitä olisi hyötyä
tuossa yhteydessä olisi client-side-sertifikaatit, joilla saisi
(pelkkää)salasanaa paremman käyttäjän tunnistuksen, mutta tuotakaan en
muista ikinä nähneeni missään muussa kuin yhdessä ite-tekemässäni
hässäkässä. Jos SSL-systeemissä käytetään pitkää keepalivetimeouttia,
niin sitä samaa voidaan käyttää myös salaamattomassa, ja mikään ei
myöskään pakota selainta tottelemaan keepalivea. Toi keepalive on
vain nopeuden optimointia, jotta ei tarvi niin paljoa yhteyden
kättelyitä, ei sessionhallintaa.
Ja jos tuo SSL kerran tarjoaan session hallinnan, niin miksi
esimerkiksi Osuuspankin webbipankki ei sitä käytä?
Ja kun nyt kerran TAAS tarttee Reijjolle kaivaa todisteita, kun se ei
muuten usko olevansa väärässä, niin alla verkkoliikenteen
kapturointia. Jossa on pelkät SYN-paketit, kun ei ton SSL-salatun
liikenteen sisällönkapturoinnista ole kauheasti iloa. IP-osoitteet on
vaihdettu a.b.c.d ja A.B.C.D:ksi
236 13.031493000 a.b.c.d A.B.C.D TCP 66 59450 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
241 13.100224000 a.b.c.d A.B.C.D TCP 66 59451 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
3659 177.602605000 a.b.c.d A.B.C.D TCP 66 59455 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
5832 325.083060000 a.b.c.d A.B.C.D TCP 66 59459 > https [SYN] Seq=0 Win=8192 Len=0 MSS=1460 WS=256 SACK_PERM=1
Tuossa capturoinnin aikana
1) palautin käyttäjätunnuksen ja pinnikoodin
2) Sen kertakäyttösalasanan
3) ja 4) klikkasin jonkun randomitoiminnon, en muista enää mitä, mutta
toinen ainakin oli tiliote. (Pidin parin minuutin tauot ennen
klikkausta, jotta keepalivet varmasti olis loppuneet)
Eli selain joka ikistä toimintoa varten avasi uuden yhteyden uusilla
porttinumeroilla (59450,59451,59455 ja 59459). Jos SSL kerran toimii
niinkuin kivenkovaan väität, niin onko sinulla jotain hyvää arvausta,
miksi Osuuspankki ei tuota toiminnallisuutta käytä vaan avaa jokaiseen
toimenpiteeseen aina uuden yhteyden? (Mun arvaukseni tuohon on se,
että sulla ei ole hajuakaan tästä(kään) asiasta, eli miten
webbipalvelut toimii ;)
Ja sen jälkeen kun tämän tein, niin keksin, että selaimen oma
verkkoliikennedebuggi olisi ollut vielä parempi, kun siitä olisi
nähnyt myös sen, mitä noissa yhteyksissä liikkuu, eikä pelkästään
yhteyden avauksia, mutta en nyt jaksanut tähän hätään, sen voit tehdä
ihan ite.
--
Arzka oh3mqu+***@hyper.fi - En halua follareita mailina
1. Valitse sopiva paikka, ei ihmisten tai rakennusten lahella, jossa
paukku voi aiheuttaa hairiota. - Iso-Kiinalaisen kayttoohje