2 ms·

It's a trap?

by RRRA 13y ago

It's a trap?

aleksis 13y ago
Ok, RTFM
quink 13y ago
With Forward Secrecy disabled when it wasn't before, it only being a quick configuration change to re-enable it (I'm talking two or three lines in Apache or nginx), and no discernible gain in disabling it other than to make it easier for people to look through the traffic after the fact... it's almost the only explanation. Either that or there's an amount of incompetence here that should might as well amount to the same degree of stay away. However, the server is probably not actively compromised, because if it was they could use PFS and still listen in. It is still required, however, that they'll need either to own this key pair being used at some point to listen in to the traffic. But that would mean that they can likely change the key pair on the server but for some reason they can't enable PFS, even though once they have access to the server in production, PFS is useless... so... who knows on that part. tl;dr: If they get the key pair later (even if years later through brute forcing or whatnot) and don't have access to the server, then PFS disabled is a bad thing. If they have control over the server or the server logs all the session keys and they receive these at some point in time, then PFS enabled is, of course, a useless thing. If they don't get the key pair at any point, then it's fine, but I'd consider that unlikely. Edit: The proper way forward is to estimate the chance they will get the key, which might as well call at 50-50, multiply that by the losses you would incur where they to gain access to these emails (and that's likely to amount to $0 for the vast majority, sorry if I'm being presumptuous and devaluing privacy) and compare that to the losses incurred if you didn't have access to these emails. Counter-intuitively arising from that, for some it might even make sense to connect assuming that traffic is intercepted, to show that they are boring and are using Lavabit for very mundane reasons.

It's a trap?

by RRRA 13y ago

It's a trap?

aleksis 13y ago

Ok, RTFM

quink 13y ago

With Forward Secrecy disabled when it wasn't before, it only being a quick configuration change to re-enable it (I'm talking two or three lines in Apache or nginx), and no discernible gain in disabling it other than to make it easier for people to look through the traffic after the fact... it's almost the only explanation. Either that or there's an amount of incompetence here that should might as well amount to the same degree of stay away. However, the server is probably not actively compromised, because if it was they could use PFS and still listen in. It is still required, however, that they'll need either to own this key pair being used at some point to listen in to the traffic. But that would mean that they can likely change the key pair on the server but for some reason they can't enable PFS, even though once they have access to the server in production, PFS is useless... so... who knows on that part. tl;dr: If they get the key pair later (even if years later through brute forcing or whatnot) and don't have access to the server, then PFS disabled is a bad thing. If they have control over the server or the server logs all the session keys and they receive these at some point in time, then PFS enabled is, of course, a useless thing. If they don't get the key pair at any point, then it's fine, but I'd consider that unlikely. Edit: The proper way forward is to estimate the chance they will get the key, which might as well call at 50-50, multiply that by the losses you would incur where they to gain access to these emails (and that's likely to amount to $0 for the vast majority, sorry if I'm being presumptuous and devaluing privacy) and compare that to the losses incurred if you didn't have access to these emails. Counter-intuitively arising from that, for some it might even make sense to connect assuming that traffic is intercepted, to show that they are boring and are using Lavabit for very mundane reasons.