For HAProxy 1.7 (may be present in older versions, didn't check), there's the 'no-ssl-reuse'[0] directive for the server.
[0]:https://cbonte.github.io/haproxy-dconv/1.7/configuration.htm...
TLS 1.2 Session Tickets
21–30 of 49 posts
Re: TLS 1.2 Session Tickets
#22I understand that TLS 1.3 is in draft stage currently. Is there an expected date of when TLS1.3 is supposed to be available in common libs and browsers ?
Also at current rate it sounds like it’s going to take years to phase out TLS 1.1. Would mordern browsers take a stand and refuse to initiate connections for older versions of TLS and its not just browsers right, there are other odd ball clients and enterprises using IE7 or something super old. I liked the way Apple had taken a stand with App Transport Security initially but even they backed down and pushed the deadline indefinitely.
Re: TLS 1.2 Session Tickets
#23Hm, looks like maybe a ticket should be filed against:
https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deploym...
As it stands, the point on resumption reads a little on the positive side?:
> 3.2 Use Session Resumption
> Session resumption is a performance-optimization technique that makes it possible to save the results of costly cryptographic operations and to reuse them for a period of time. A disabled or nonfunctional session resumption mechanism may introduce a significant performance penalty.
Does http2 have similar issues with session resumption (especially: compromised pfs)?
I came across this, which documents how cloudscape does this securely - at least they rotate - but looks like read access to memcache+compromise of a single web server is enough to compromise the past hour or two of ssl traffic that goes through cloudflare?
https://blog.cloudflare.com/tls-session-resumption-full-spee...
[ed: also came over this:
https://github.com/mozilla/cipherscan
Which looks very handy for sanity-checking servers.]
Re: TLS 1.2 Session Tickets
#24Hm, looks like maybe a ticket should be filed against: https://github.com/ssllabs/research/wiki/SSL-and-TLS-Deploym... As it stands, the point on resumption reads a little on the positive side?: > 3.2 Use Session Resumption > Session resumption is a performance-optimization technique that makes it possible to save the results of costly cryptographic operations and to reuse them for a period of time. A disabled or non…
> I came across this, which documents how cloudscape does this securely - at least they rotate - but looks like read access to memcache+compromise of a single web server is enough to compromise the past hour or two of ssl traffic that goes through cloudflare?
but (depending on how you get in) you can probably also compromise the next few hours, so one extra hour doesn't seem like a huge difference, given that the scenario is somewhat unlikely in the first place.
Re: TLS 1.2 Session Tickets
#25We are doing all these session tickets gymnastic to reduce the round trip. Mostly considering web applications. In case of native mobile application, we could just add a splash-screen/quick 2 sec animation hiding the worst case 3x200ms round trip latency overhead. So at the start of the app we simply create a fresh perfectly secured TLS connection. It appears a better choice from security standpoint, UI can always be…
It's not just reducing RTT latency; it's also reducing the number of bignum crypto operations the server needs to perform, which carry a significant computational cost.
Re: TLS 1.2 Session Tickets
#26Earlier quoted context omitted.
So it would be correct to say that if any of Cloud Flare's endpoint servers is compromised, the adversary can decrypt traffic passively on a global scale?
I assume that's the point With Anycast I don't think you have the choice of not georeplicating the STEK. And latency is one of their biggest selling points. So you could say they are trying to make the best of a bad situation. It is absolutely bizarre that the STEK-encrypted session key is not itself sent inside the session encrypted channel.
You do have the choice. You don't need session tickets at all to run TLS. The cost of geographically-distinct STEKs would simply be an additional handshake if the client hops regions. (Is this common?)
This is a choice Cloud Flare is making in favor of performance, and it seems sort of risky with respect to a well-funded global adversary. This makes persistent access to any single endpoint server incredibly valuable.
But maybe regional STEKs are impractical from a performance perspective. I assume Cloud Flare has performance measurements to justify this choice. I'd be interested to read a blog post about it.
Re: TLS 1.2 Session Tickets
#27> An attacker with the STEK doesn't need to wait until session resumption is attempted. Session Tickets containing the current session keys are sent at the beginning of every connection that merely supports Session Tickets. In plaintext on the wire, ready to be decrypted with the STEK, fully bypassing Diffie-Hellman. I found this flaw to be the scariest, by far. It means that a connection with "forward secrecy" gives…
Gives up the property before it begins even. But I completely agree with you. I would go as far to say a connection does not have PFS if you are sending the DH session key encrypted only by a [geographically replicated] static key before the session starts. You are literally destroying the entire purpose of the DH handshake in doing so. I always assumed the STEK-encrypted session key was sent inside the established T…
You're clearly not destroying the entire purpose of the DH handshake, because the STEK is rotated and so the time window of compromise is limited to by the rotation interval. Even with poorly rotated ticket keys, you're still better off with a PFS suite than without it --- without the DH, every client has an unlimited window of exposure if the server's private key is compromised.
Re: TLS 1.2 Session Tickets
#28Earlier quoted context omitted.
Gives up the property before it begins even. But I completely agree with you. I would go as far to say a connection does not have PFS if you are sending the DH session key encrypted only by a [geographically replicated] static key before the session starts. You are literally destroying the entire purpose of the DH handshake in doing so. I always assumed the STEK-encrypted session key was sent inside the established T…
You're clearly not destroying the entire purpose of the DH handshake, because the STEK is rotated and so the time window of compromise is limited to by the rotation interval. Even with poorly rotated ticket keys, you're still better off with a PFS suite than without it --- without the DH, every client has an unlimited window of exposure if the server's private key is compromised.
True, it does not destroy the entire purpose if and when the STEK is securely and properly rotated. But to call this PFS stretches the truth in ways that boring crypto never does.
The number of real-world cases where PFS is reduced exactly to the non-PFS state by the existence of session tickets with fixed STEKs is not only non-zero, but rather I would venture a guess it is staggeringly large.
E.g. Configuring Session Tickets [1]
While Apache offers the SSLSessionTicketKeyFile directive to specify a key file that should contain 48 random bytes, it is recommended to not specify one at all. Apache will simply generate a random key on startup and use that to encrypt session tickets for as long as it is running.
The good thing about this is that the session ticket key will not touch persistent storage, the bad thing is that it will never be rotated. Generated once on startup it is only discarded when Apache restarts. For most of the servers out there that means they use the same key for months, if not years.
To provide forward secrecy we need to rotate the session ticket key about daily and current Apache versions provide no way of doing that. The only way to achieve that might be use a cron job to gracefully restart Apache daily to ensure a new key is generated. That does not sound like a real solution though and nothing ensures the old key is properly overridden.
...
Nginx, too, provides no way to automatically rotate keys. Reloading its configuration daily using a cron job might work but does not come close to a real solution either.
...
HAproxy does not allow configuring session ticket parameters. It implicitly supports this feature because OpenSSL enables it by default. HAproxy will thus always generate a session ticket key on startup and use it to encrypt tickets for the whole lifetime of the process.
[1] - https://timtaubert.de/blog/2014/11/the-sad-state-of-server-s...
Note that's from 2014 -- has it changed since then?
Re: TLS 1.2 Session Tickets
#29I understand that TLS 1.3 is in draft stage currently. Is there an expected date of when TLS1.3 is supposed to be available in common libs and browsers ? Also at current rate it sounds like it’s going to take years to phase out TLS 1.1. Would mordern browsers take a stand and refuse to initiate connections for older versions of TLS and its not just browsers right, there are other odd ball clients and enterprises usin…
We are still working around bugs in network middleware. I hope that it will be available in Chrome and on Google's servers in Q1, 2018.
Re: TLS 1.2 Session Tickets
#30Earlier quoted context omitted.
You're clearly not destroying the entire purpose of the DH handshake, because the STEK is rotated and so the time window of compromise is limited to by the rotation interval. Even with poorly rotated ticket keys, you're still better off with a PFS suite than without it --- without the DH, every client has an unlimited window of exposure if the server's private key is compromised.
True, it does not destroy the entire purpose if and when the STEK is securely and properly rotated. But to call this PFS stretches the truth in ways that boring crypto never does. The number of real-world cases where PFS is reduced exactly to the non-PFS state by the existence of session tickets with fixed STEKs is not only non-zero, but rather I would venture a guess it is staggeringly large. E.g. Configuring Sessio…
The 'P' in 'PFS' has always stretched the truth, which is why a lot of practitioners elide it.
Even if you never rotate STEKs and never reset systems to get a new STEK accidentally, the DH handshake is still providing forward secrecy value for clients who don't do session tickets.