Google: Maintaining digital certificate security
Google: Maintaining digital certificate security
Posted Mar 25, 2015 19:09 UTC (Wed) by dlang (guest, #313)In reply to: Google: Maintaining digital certificate security by pizza
Parent article: Google: Maintaining digital certificate security
A case I ran into a few years back was where we had a site that was mostly open to the public, but we wanted one subdirectory to be protected by a client cert. This required renegotiating the connection.
Yes, in theory it could allow to renegotiate to a stronger connection and not to a weaker one, but how _exactly_ do you define in an unambiguous way which options are stronger than others? Especially as new vulnerabilities are discovered.
Posted Mar 25, 2015 19:22 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
> A case I ran into a few years back was where we had a site that was mostly open to the public, but we wanted one subdirectory to be protected by a client cert. This required renegotiating the connection.
A real protocol should have an optional authentication layer built on top of it. I.e. you establish a secure connection and then use it to transmit a signed token that proves that it's really you (the token must include a hash of the transport-level parameters). There's absolutely no need to renegotiate lower transport levels for that.
Posted Mar 25, 2015 19:46 UTC (Wed)
by dlang (guest, #313)
[Link]
This is not the case. At most you could say that encryption is "strong enough" against a particular threat model.
but just because the NSA could crack something with a datacenter full of computers doesn't mean that the encryption is worthless if what you are trying to protect against is a child in your family.
As for no encryption being stronger than any other, 512 bit RSA keys are not as strong as 4096 bit RSA keys. At one point 512 bit keys were 'strong enough', but now they generally are not considered to be 'strong enough' against any non-trivial threats.
Google: Maintaining digital certificate security
No you don't. There shouldn't be 'stronger parameters'. Encryption is either strong or useless.
Client cert _authentication_ does not mean 'stronger parameters', it just means that.
Google: Maintaining digital certificate security