For example, when authenticating to a TLS protected service, and then closing the tab, you can sometimes reconnect to the service afterwards without re-authenticating.
In preservation of perfect forward secrecy, the key should be deleted after the session terminates. Does the session only "terminate" when the browser closes, or is there a "Time To Live"-like expiration on session keys not in use?
Are TLS session keys cached in a browser?
Yes, sometimes, but not as you're describing.
The simplest bottom line answer for you is "Yes, sessions are cached until the browser is closed." That's not absolutely true, or true in all cases, but it's a reasonably secure belief for you to base your actions upon.
when authenticating to a TLS protected service, and then closing the tab, you can sometimes reconnect to the service afterwards without re-authenticating.
What you're describing here is that you authenticated to a web application which you browsed to using a TLS connection. Unless you were prompted to provide a client certificate the first time through, the authentication is not for TLS, it's for the app.
That app is probably using cookies, and those cookies mean that when you go back in another tab, it recognizes you and you don't need to authenticate again. Depending on the setup, this authenticated state may also persist past a browser close and restart, system sleep, and IP address change! I've had authenticated web sessions work on either side of a day of air travel.
(Even if you were prompted for a client certificate... browsers will remember your selected certificate and re-present it as necessary until you close the browser. Closing the tab would not impact that.)
In preservation of perfect forward secrecy, the key should be deleted after the session terminates. Does the session only "terminate" when the browser closes, or is there a "Time To Live"-like expiration on session keys not in use?
Realistically, the speedup provided by session resumption outweighs the potential negative of re-using keys - keep in mind that most HTTP transactions are astonishingly small, whereas PFS becomes a larger practical concern with protocols like IPSec that will be up for days/weeks/months and swap large chunks of data.
So, in practical terms, browsers will remember recent TLS session IDs and use them to try and shortcut the TLS negotiation process. Closing a tab will not cause them to be forgotten (although closing the browser probably will). They are used invisibly; the use of one cuts down on 4-8 packets of back-and-forth when setting up TLS and thus speeds the connection up.
But - again - this has nothing to do with authentication you might see, and takes place quietly, behind the scenes.
The "time-to-live" is determined by both the client (who has to remember the session ID) and the server (who also has to remember the session ID). There's a good article here which talks about how to tweak the cache for various servers to limit the amount of past sessions that would be compromised if the server is compromised.
And this interesting answer suggests that Chrome and Opera stores session keys infinitely until browser restart (or other limited situations).
