Are SSL browser sessions kept alive across requests?

Question

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?

Answer 1

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.

Answer 2

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.