0

I'm trying to understand the concept of ephemeral session keys as it pertains to perfect forward secrecy. There's an example I wasn't sure if.

Let's say I have a webpage served over TLS at the url https://acmecorp.com. The webpage has 5 <img src="" /> tags with src that references image files on the same server/domain , hence they use relative paths.

When Firefox opens up https://acmecorp.com for the first time, after the page fully loads, does that mean 6 ephemeral session keys were made? One for the html content and five for the five images?

And if I press reload on the webpage, does that mean 6 new ephemeral session keys will have been made and used?

Improve this question
1
  • 1
    If you use a relative URL it is necessarily on the same host (and scheme), but even if you use an absolute URL the browser can recognize it's the same host and re-use an existing connection. Commented May 24, 2024 at 0:49

1 Answer 1

Reset to default
2

The number of key exchanges depend on the HTTP protocol and TLS protocol used, which depend on the capabilities and behavior of client and server.

In the best case of HTTP/2, HTTP/3 or HTTP/1 with keep-alive all requests are send over a single TLS connection, which means only one key exchange. In the worst case there will be a new TLS connection for each new request with no session resumption to the other ones. This means one key exchange per request.

If the server supports HTTP/2 or HTTP/3 it is very likely that everything will be done over one TLS connection (assuming that all requests go to the same host). These protocols support sending multiple requests at the same time (interleaved) over the same connection.

With HTTP/1 and keep-alive the requests can only be send sequentially inside the a single connection. To allow some parallel requests browsers will therefore usually open multiple TCP connections to the host, which means multiple TLS connections too. Up to TLS 1.2 this might still mean a single key exchange if the session is shared between the TLS connections. With TLS 1.3 a new key exchange is made for each new TLS connection even if a sessions gets resumed.

With HTTP/1 and no keep-alive a new TCP/TLS connection will be made for each new request. If these share the same TLS session there will be only one key exchange for TLS protocol up to TLS 1.2. Without shared session or with TLS 1.3 there will be a new key exchange for each connection.

Improve this answer
4
  • 1
    Either HTTP/1 keepalive OR HTTP/2 multiplexing can do multiple resources from the same host over one connection. But Firefox in particular does two connections automatically even if only one is needed. Resumption in 1.3 doesn't reuse the master secret as earlier versions did, and anyway the master secret is not the actual key; two or four working keys (and zero or two IVs) are derived depending on version and cipher class, and even with reused-master resumption (1.2 down) these mix the hello.random values and thus differ for each connection. Commented May 24, 2024 at 0:49
  • 1
    @dave_thompson_085: thanks for the input. I've reworked my answer based on your comment. Commented May 24, 2024 at 3:27
  • And if I'm understanding correctly, if using http/3 and if user presses reload on a web page, then it is likely a new ephemeral session key will be made? Commented May 25, 2024 at 13:43
  • 1
    @learningtech: not necessarily. The existing connection might still be establish and thus can be reused. Commented May 25, 2024 at 13:46

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.