Timeline for Are SSL browser sessions kept alive across requests?
Current License: CC BY-SA 3.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Feb 12, 2016 at 7:12 | comment | added | AviD♦ | @NeilSmithline that's... that is... huh. That is very odd. In Wikipedia's OSI entry, it specifically does note that it is a conceptual model only... Weird. Perhaps we should update that Wikipedia article... | |
| Feb 11, 2016 at 18:41 | history | edited | Neil Smithline | CC BY-SA 3.0 | deleted 305 characters in body |
| Feb 11, 2016 at 18:40 | comment | added | SilverlightFox | SSL might not know about HTTP, but HTTP can know about SSL - therefore it could get the session identifier in order to maintain an HTTP session. See this answer for more details - I'm not saying necessarily that it's a good idea though. | |
| Feb 11, 2016 at 18:21 | history | edited | Neil Smithline | CC BY-SA 3.0 | added 13 characters in body |
| Feb 11, 2016 at 18:19 | comment | added | Neil Smithline | @AviD - I can't say that I'm a huge OSI fan either. It feels so 1970's to me. That said, I did pull that fact out of the Wikipedia's TLS entry. I don't have time at the moment, but I'll try to come back and tweak that last paragraph. | |
| Feb 11, 2016 at 15:40 | comment | added | AviD♦ | Aww that was a great answer up until the very last paragraph.... You're wrong there, SSL/TLS is NOT in layer 6 of the OSI model. Do you know why? BECAUSE SSL/TLS IS NOT AT ALL IN THE OSI MODEL. Oops, sorry for shouting, but the OSI model is not used, it is not even real, it is merely a "conceptual model". TCP/IP is a complete separate, if vaguely similar, model to OSI. </nitpicking> I just wish people would stop saying OSI when they mean "layers of the TCP/IP stack"... ;-) | |
| Feb 11, 2016 at 13:00 | comment | added | Boris the Spider | @LieRyan I think I may have given a crappy link - there is a SessionTrackingMode.SSL specified in the Java EE spec that ties the HTTP session to the SSL session. Whether that's a good idea I don't know - but it is possible and part of the spec for a very major web application platform. | |
| Feb 11, 2016 at 12:58 | comment | added | Lie Ryan | @BorisTheSpider: Tying TLS sessions with HTTP session opens you up to various issues: no control over session lifetime, load balancing, and wise it facilitates session hijacking. If the user is subject to corporate SSL interception proxy which are configured to reuse outgoing TLS connection, you're going to have fun with users seeing each other's confidential data. | |
| Feb 11, 2016 at 12:57 | comment | added | Lie Ryan | @BorisTheSpider: the premise of that blog post is ridiculous. If you want to eliminate Man in the browser (MitB), cut the crap with trying to tie TLS session, just set the Secure and HttpOnly attributes on your cookies and use TLS as usual. That's all you need to secure an HTTP session against MitB session hijacking. | |
| Feb 11, 2016 at 8:53 | comment | added | Boris the Spider | Not entirely true, Java EE (as an example) supports using SSL sessions to keep HTTP sessions alive. This avoids all the cookie and url rewriting nonsense and closes many session hijacking security holes... | |
| Feb 10, 2016 at 23:28 | history | answered | Neil Smithline | CC BY-SA 3.0 |