5 ms·

I learned few years ago that you can do TLS auth without client side certs. People were always surprised how they stay logged in after clearing cookies.

BiteCode_dev 6y ago
Do you have a link to a tutotial for that ?
- baybal2 6y ago
  No, but it's very easy to grasp. https://blog.cloudflare.com/tls-session-resumption-full-speed-and-secure/ https://blog.cloudflare.com/tls-session-resumption-full-spee... did it perfectly. Basically, you need to get the session ticket from the webserver being available at the backend, and set its lifetime to something reasonable. At least NGINX can then handle all of the session resume/renew logic by itself.
luto 6y ago
Which TLS feature are you referring to?
- spockz 6y ago
  I think he might be referring to tls sessions. When a client comes back to a server it remembers that it connected to it can send a session Id encrypted with the master secret or a complete session ticket. When the handshake completes successfully you know who it was if you stored that information. It saves using a cookie. Also it might not be supported in every client. I think you still need to have mTLS or another credential to use initially for auth. Unless I miss an option. As such I don’t see much value over mtls in a corporate network setting.
  - ALOHa100 6y ago
    https://blog.cloudflare.com/tls-session-resumption-full-speed-and-secure/ https://blog.cloudflare.com/tls-session-resumption-full-spee...
ivanr 6y ago
What you're describing can be achieved by misusing TLS session IDs, but the technique doesn't work reliably and it's not secure. In essence, when client and server handshake, a unique session ID is generated. The server can associate this ID with a user account and use it to identify the user on subsequent requests. Except this works only when client and server are connected directly. If there is a CDN in front of the server, or a proxy in front of the client, the session ID will refer to the intermediary devices, which may be used among many users, and so on. In addition, clients can (and often do) throw away TLS sessions very frequently. The last time I tried this technique (admittedly some two decades ago) Internet Explorer was rotating the session ID every 5 minutes. There is something called Channel Binding (or Token Binding, the names have changed a couple of times) that can be used to create a cryptographic identity at TLS level. It's the same idea as session ID binding, just properly secure. Google spent a lot of time experimenting with it but IIRC ultimately decided against it. Here's a link to the slides from a couple of years ago: https://tools.ietf.org/agenda/90/slides/slides-90-uta-0.pdf https://tools.ietf.org/agenda/90/slides/slides-90-uta-0.pdf There is also in TLS something called pre-shared key (PSK) authentication, which is a way to handshake without certificates, but client and server have to share a password instead. (In TLS 1.3, the PSK mechanism is also used for session resumption.)
- baybal2 6y ago
  FYI CloudFlare uses it massively, and has, CDN-wide as I believe, session cookie resume.
  - deleted 6y ago
    [deleted]
- tialaramex 6y ago
  > There is also in TLS something called pre-shared key (PSK) authentication, which is a way to handshake without certificates, but client and server have to share a password instead. It is imperative to understand that passwords are not suitable for a TLS 1.3 PSK. I even ran into this with some people working on CMP in LAMPS ("Limited Additional Mechanisms for PKIX and S/MIME" the poor group left with the work that couldn't be avoided entirely to fix problems in PKIX and/or S/MIME) No, you can't just run the password through PBKDF2 and consider that good enough. If you really need password authentication, you need an actual password based authentication mechanism, do not try to jury rig PSKs.
cyberlab 6y ago
Does spawning new incognito sessions mitigate this? I know for me I have set all my various browsers to use incognito mode by default, so all my sessions are insulated from each other and can't 'talk' to each other. For sessions where I need to be logged in/use cookies, I have a dedicated Firefox profile that I launch with the `-p` switch in the launcher icon, and I never do anything sensitive in this session, so I don't care about secrets being leaked into that session.
- baybal2 6y ago
  I don't know

BiteCode_dev 6y ago

Do you have a link to a tutotial for that ?

baybal2 6y ago
No, but it's very easy to grasp. https://blog.cloudflare.com/tls-session-resumption-full-speed-and-secure/ https://blog.cloudflare.com/tls-session-resumption-full-spee... did it perfectly. Basically, you need to get the session ticket from the webserver being available at the backend, and set its lifetime to something reasonable. At least NGINX can then handle all of the session resume/renew logic by itself.

luto 6y ago

Which TLS feature are you referring to?

spockz 6y ago
I think he might be referring to tls sessions. When a client comes back to a server it remembers that it connected to it can send a session Id encrypted with the master secret or a complete session ticket. When the handshake completes successfully you know who it was if you stored that information. It saves using a cookie. Also it might not be supported in every client. I think you still need to have mTLS or another credential to use initially for auth. Unless I miss an option. As such I don’t see much value over mtls in a corporate network setting.
- ALOHa100 6y ago
  https://blog.cloudflare.com/tls-session-resumption-full-speed-and-secure/ https://blog.cloudflare.com/tls-session-resumption-full-spee...

ivanr 6y ago

What you're describing can be achieved by misusing TLS session IDs, but the technique doesn't work reliably and it's not secure. In essence, when client and server handshake, a unique session ID is generated. The server can associate this ID with a user account and use it to identify the user on subsequent requests. Except this works only when client and server are connected directly. If there is a CDN in front of the server, or a proxy in front of the client, the session ID will refer to the intermediary devices, which may be used among many users, and so on. In addition, clients can (and often do) throw away TLS sessions very frequently. The last time I tried this technique (admittedly some two decades ago) Internet Explorer was rotating the session ID every 5 minutes. There is something called Channel Binding (or Token Binding, the names have changed a couple of times) that can be used to create a cryptographic identity at TLS level. It's the same idea as session ID binding, just properly secure. Google spent a lot of time experimenting with it but IIRC ultimately decided against it. Here's a link to the slides from a couple of years ago: https://tools.ietf.org/agenda/90/slides/slides-90-uta-0.pdf https://tools.ietf.org/agenda/90/slides/slides-90-uta-0.pdf There is also in TLS something called pre-shared key (PSK) authentication, which is a way to handshake without certificates, but client and server have to share a password instead. (In TLS 1.3, the PSK mechanism is also used for session resumption.)

baybal2 6y ago
FYI CloudFlare uses it massively, and has, CDN-wide as I believe, session cookie resume.
- deleted 6y ago
  [deleted]
tialaramex 6y ago
> There is also in TLS something called pre-shared key (PSK) authentication, which is a way to handshake without certificates, but client and server have to share a password instead. It is imperative to understand that passwords are not suitable for a TLS 1.3 PSK. I even ran into this with some people working on CMP in LAMPS ("Limited Additional Mechanisms for PKIX and S/MIME" the poor group left with the work that couldn't be avoided entirely to fix problems in PKIX and/or S/MIME) No, you can't just run the password through PBKDF2 and consider that good enough. If you really need password authentication, you need an actual password based authentication mechanism, do not try to jury rig PSKs.

cyberlab 6y ago

Does spawning new incognito sessions mitigate this? I know for me I have set all my various browsers to use incognito mode by default, so all my sessions are insulated from each other and can't 'talk' to each other. For sessions where I need to be logged in/use cookies, I have a dedicated Firefox profile that I launch with the `-p` switch in the launcher icon, and I never do anything sensitive in this session, so I don't care about secrets being leaked into that session.

baybal2 6y ago
I don't know