HTTPS encryption - multiple accounts on one website

[whitenoise]

Hey,

does anyone know how this is handeled? Let's say i.e. I have two accounts for google. I connect to google and there will be a TLS handshake, I log in and everything is fine. Now I open another tab with google and log into my second account. I know that the accounts are distinguished by the cookie and the session ID but what is with the HTTPS encryption? In both tabs will there be the same key for encryption? And if not - how does the server/browser know which key to use? Is there such a thing like a TLS session ID ?

Thanks for your input!

//Update: I just did some wireshark research on that. First of all there is a session ID for TLS, it is set after the handshake, so there is

Client Hello

Server Hello

Certificate, Server Key Exchange

Client Key Exchange

and after this negotiation the session ticket is set.

I recorded some packets with wireshark and loaded google multiple times in my browser. Basically each time the procedure is the same as described above. The session ticket always changes but the first 32 bytes seem to be the same every time. Maybe this is some kind of header information? I don't know yet.

Nevertheless, after this, the traffic is encrypted and also the TLS session id seems to be encrypted because I cannot find it in the plain text part of the packet. Somehow strange. So the packet arrives at the server but where does the server know which i.e. AES key to use for decryption? I'm still a bit confused.

Edited October 7, 2015 by whitenoise

[digininja]

You are mixing up connections and sessions.

If you are talking about tabs in a single browser then you will probably have a different connection per tab. HTTP uses a "keep-alive" header that can keep the connection open for multiple requests but I'm pretty sure that will be per tab.

Your browser will have a single set of cookies for each site and won't care what tab you are in, the cookies will be sent with each request where the fields match - domain/path/http or https. So if you log into a site in one tab then the session will be established and the session cookie sent to the browser, each subsequent request the browser will send that session cookie back regardless of what tab it is in so you will only have a single session that will cover multiple tabs.

You can think of the server side as two parts, the first part is the crypto bit, it handles the encryption and strips it off then the clear text stuff comes out, including the cookies, and they are then passed into the web app. That way the web app doesn't need to know or care about the communication level, it just gets clear text info to handle.

[whitenoise]

@digininja: Exactly, the part where cookies and different accounts come into play is 100% clear. It is also clear that the http layer is encapsulated in the encryption layer. Once everything is decrypted the http header contains all the session information for the website. But still, how is the encryption layer handeling sessions? Multiple tabs seem to result in multiple sessions, also session IDs are negotiated after the TLS handshake. What I don't understand yet is how the server distinguishes between all the sessions comming from the different tabs as there is no TLS session ID in the encrypted packets. For me it would be rational to have a TLS header with a session ID so the server can match it with the negotiated key to decrypt/encrypt the payload. I'm quite sure the server does not bruteforce the payload with all its known keys and see if one works ;)

Edited October 7, 2015 by whitenoise

[digininja]

don't understand what you mean by the encryption layer handling sessions, if you mean encryption sessions rather than user sessions then they are based on TCP connections. Each time a connection is made the underlying TCP connection is tied to a process or thread and keys are negotiated.

[whitenoise]

@digininja: Okay, TCP means we have a source-ip, source-port, destination-ip, destination-port, then there are ack-numbers and sequence-numbers for all the data and a bunch of flags (+checksum). However there is not really a session ID in the TCP segment of the packets. There has to be something distinct. So would you say the keys are bound to processes running on the server? Are all TCP connections followed after the TLS handshake (which also includes a TCP segment) kind a child-connections from that TLS handshake TCP connection?

[digininja]

TCP is a session based protocol compared to UDP which is sessionless, just Google for it, there is loads of info on it.

[cooper]

To your local system the thing that uniquely identifies the connection between your machine and the other system is the combination of local port, local interface ip, remote host interface IP and remote port. Every packet that has those 4 pieces the same belongs to the same connection so you can group them together.

The sequence number, a TCP feature lacking in UDP, means TCP knows the order in which packets were sent so it can provide the data to the program exactly like the sender sent it out - with UDP packets can overtake each other and it would be undetectable by the UDP stack. Also, packets must be numbered in order, so if you get packet 3 then packet 5 you know 4 is missing so first you wait a while and then ask the remote server to resend packet 4. This is the reliability feature of TCP in action.

Moving up, we have HTTP which uses TCP to perform its magic. HTTP is connection-less, meaning that the general concept is that the client sends a request to the server, the server answers the request and then the client and server terminate their connection. They do this for each and every request the client needs to make to the server. Now, a request can span multiple TCP packets and a response can span multiple packets. All those packets will have the same 4 fields for port and IP as mentioned before. Once the connection is severed at the TCP level nothing remains. Because of this, HTTP invented web sessions - a unique ID it can include in its outgoing request that allows the server to uniquely identify the remote HTTP client over multiple TCP connections. Allowing one request to bring the user to the login page and a subsequent request to inform the server the client is in fact user 'whitenoise', which can be verified because *this* is his password.

At some point early on in the game people discovered that with this connection-less protocol a lot of packets were being wasted on creating and shortly thereafter destroying connections between the same client and server, so they amended the spec to allow the client to keep the connection open after the response was received and allowing the client to send additional requests. But to the server, each request is treated as a thing in and of itself. It has no memory of past interactions with the client outside of what's being relayed in the current request.

Later still, people found that if you sniff that session id from the line and use it for your own communication with the server, the server would be unable to distinguish the two of you, which can be quite a nice feature when the other user is an admin and you've always wanted to be one of those. To the admin it was a bit less of a desired effect, so encryption was applied. This encryption lives between the HTTP layer and the TCP layer. You start with a TCP connection between yourself and the remote server. Then encryption layer then sets up the local and remote side of the connection such that the data transmitted over TCP is just random garbage, but with the correct key you get the original plain-text HTTP request and response. But the original characteristics of HTTP still apply, so the connection can be severed by the client after each request without anything happening to the HTTP client's behavior. It would still show webpages, allow you to log in and out, etc because it still includes, in its outgoing and now encrypted requests the unique session id.

Regarding your original question of how the server knows which crypto to use in its encryption layer, it's part of how the encryption layer establishes its connection. Basically, as part of the set up for the protocol, the client tells the server the full set of cryptographic ciphers and hashes it's willing to use to create a connection with the server. The server now either picks the strongest ones it's willing to accept and informs the client, or breaks off the connection because it can't be made sufficiently secure by its own standards. The chosen crypto will be used exclusively during this connection. It may be that for a later connection a different type of crypto is used, but that would only happen because you told your client to allow different algorithms and the server found that what was previously the best that it also supports is now either not available anymore, or there's an even better one. It's completely legal and will be otherwise transparent to the HTTP client, but it'll naturally be a rare occurrence in real life.

[whitenoise]

@cooper: Thanks for this nice summary about TCP and HTTP layers working together. How these layers work is clear to me. I conclude that the tuple of src-ip, src-port, dst-ip and dst-port identify to a unique connection and therefore I would say HTTPS keys are stored together with this connection information. However the HTTPS port on most webservers is port 443 so the tabs inside a webbrowser can target the same https website but each outgoing connection uses another port so inside the browser this connection is tied to the keys and is distinct by the ip address of the user and in case of the tabs by the portnumbers.

Thanks to both of you for clearing this up to me.

[cooper]

I conclude that the tuple of src-ip, src-port, dst-ip and dst-port identify to a unique connection and therefore I would say HTTPS keys are stored together with this connection information.

Which is wrong. The lifetime of the HTTPS keys exceeds that of any single connection and the same key can be used for multiple, separate and simultaneous connections.

Your browser should associate its HTTPS session with a specific tab, but this is seemingly kinda difficult because if you follow a link on an HTTPS site and tell your browser to open that link in a new tab, you now have 2 tabs that must use the same HTTPS key. If you open third tab and go to the same website, should the browser now use the same HTTPS key for this session, or start a new one? How about when you do this without opening a new tab, so on the tab you created by following a link on the HTTPS website? What about when you go to a completely unrelated website and then do this? How about when you use the 'back' button? This is why browsers have such a hard time doing 2 separate HTTPS sessions with the same website - it's almost impossible to keep them properly separated.

[whitenoise]

if you follow a link on an HTTPS site and tell your browser to open that link in a new tab, you now have 2 tabs that must use the same HTTPS key

Totally makes sense to me. It's still not clear to me how this finally is working :S Obscured internal processing? huh?

[cooper]

Your HTTP session key is retained either in the URL as a parameter (rare) or in a cookie.

Cookies are only domain-specific so any communication the browser has with that domain, regardless of tab, will include the cookie data.

[whitenoise]

I'm only interested in HTTPS not in HTTP. HTTP sessions are clear to me. It is all about how the encryption keys of a https connection are stored and referenced to the right connection. For me there has to be some kind of table somewhere looking like:

ip:port <-> ip:port | key1

ip:port <-> ip:port | key2

ip:port <-> ip:port | key3

...

And each time a new https connection is established with all the client hello and server hello and so on after the negotiation the server and also the browser needs to add that connection to a table to refer encrypted content (incoming payloads) and unencrypted content (outgoing stuff) to a key that is used for the encryption/decryption so both partners speak the same language.

Edited October 11, 2015 by whitenoise

[cooper]

HTTPS is HTTP over encrypted sockets.

The encryption keys are socket-specific. A socket is data flowing between src_ip:src_port and dst_ip:dst_port. If you make a new socket, you renegotiate the crypto and whatever keys are involved there.