Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When a client requests an SSL web resource via a browser (ie: a login request) and then follows up with additional requests are all the requests executed in the same SSL session? Or does the browser create and tear down the session with each request?

And do servers track session state across these requests solely through cookies which are encrypted over the SSL protocol or is there any functionality provided through SSL where servers know that the initial request came from the same browser as the following requests? If it's just via encrypted cookies what is to prevent someone from spoofing the cookie value somehow and making a request with that spoofed cookie thus impersonating the original user?

share|improve this question

TL;DR: HTTP sessions and SSL sessions are different entities and there is no mapping from one to the other.

Onto the specifics...

When a client requests an SSL web resource via a browser (ie: a login request) and then follows up with additional requests are all the requests executed in the same SSL session?

Either the server or the client can terminate an SSL connection, but, for performance reasons, existing sessions are reused when possible.

do servers track session state across these requests solely through cookies which are encrypted over the SSL protocol or is there any functionality provided through SSL where servers know that the initial request came from the same browser as the following requests

Cookies are typically the sole mechanism of session maintenance when communicating with a browser. Alternatives can be session IDs passed as hidden fields or sessions managed by custom JavaScript existing on the page. In fact, clients can multiplex multiple sessions over a single SSL connection. The one exception to multiplexing sessions is when mutual authentication is used. When this occurs, the client is authenticated during the TLS handshake. Establishing identity isn't the same as establishing a session, but they are certainly related.

If it's just via encrypted cookies what is to prevent someone from spoofing the cookie value somehow and making a request with that spoofed cookie thus impersonating the original user?

You are referring to session hijacking. Some strategies that are used to prevent session hijacking are choosing a difficult to guess session ID (long and random is generally best), only passing the session ID cookie via SSL to prevent network snooping, and not allowing the session ID cookie to be accessed via JavaScript. Unfortunately, despite all of those defenses, Broken Authentication and Session Management continues to be the second most common security flaw according to the OWASP 2013 Top-10.

share|improve this answer
    
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... – Boris the Spider Feb 11 at 8:53
    
@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. – Lie Ryan Feb 11 at 12:57
    
@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. – Lie Ryan Feb 11 at 12:58
    
@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. – Boris the Spider Feb 11 at 13:00
    
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"... ;-) – AviD Feb 11 at 15:40

HTTP sessions and TLS sessions are independent.

HTTP keeps track of session usually with HTTP cookies. Requests from a single HTTP session can be sent over multiple TLS connections each with their own TLS sessions.

TLS session is tracked with TLS session ticket. Session ticket keeps track of the encryption parameters (which cipher to use, session key, etc); encryption parameters is usually associated with a single TLS connection, but TLS can also resume a TLS session to create a new TLS connection with the same encryption parameters as a previous connection.

Also, if you have a proxy server, it can multiplex multiple requests from different clients into a single TLS connection, and this means you may have multiple HTTP session in a single TLS connection.

When a client requests an SSL web resource via a browser (ie: a login request) and then follows up with additional requests are all the requests executed in the same SSL session? Or does the browser create and tear down the session with each request?

This is implementation defined. User agents may decide to use multiple TLS connections and/or sessions if it believes doing so will be beneficial to performance. Modern browser will typically open several TLS connections to make HTTP/1.1 requests concurrently up to a limit (usually 4-8 concurrent connections), then reuses those connections as much as possible. Modern browsers will usually use a single TLS connection for HTTP/2 requests as HTTP/2 supports request multiplexing natively.

And do servers track session state across these requests solely through cookies which are encrypted over the SSL protocol

HTTP Servers tracks HTTP session through HTTP cookies only. The TLS part of the Web Server tracks TLS connections, but this is independent of the HTTP sessions. Some Web Server can also use mutual authentication to authenticate user via SSL client certificate; and this can be used to track session as well if the server is configured to pass information about the client certificate into the HTTP request (e.g. as HTTP headers).

or is there any functionality provided through SSL where servers know that the initial request came from the same browser as the following requests?

TLS has session tickets to keep track of TLS sessions.

If it's just via encrypted cookies what is to prevent someone from spoofing the cookie value somehow and making a request with that spoofed cookie thus impersonating the original user?

If an attacker can somehow gets hold of the cookie from your user's browser, you're already screwed.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.