Default "secrets"

Posted Jan 6, 2011 10:46 UTC (Thu) by Fowl (subscriber, #65667)
Parent article: Default "secrets"

Perhaps I misunderstand SSL, but I thought that the certificate was only useful to ensure the identity, not to encrypt the session. I mean each session has randomised session keys not based on the private key.

The private key is just to prove that you are the server you say you are, either by a trusted 3rd party you already have the keys for or key continuity management - store the key the first time and hope that your first connection isn't compromised! ("the ssh model")

So yes, having the same private key would in effect allow anyone to pretend to be your device, but without MITM that shouldn't be that useful. That's not to say that it's a good situation, clearly SSL (and SSH!) keys should be generated on first boot, with an opportunity to upload "real" keys.

Or am I on the wrong track entirely?

to post comments

Default "secrets"

Posted Jan 6, 2011 12:38 UTC (Thu) by erwbgy (subscriber, #4104) [Link] (1 responses)

The public and private keys are used when exchanging the session key, so if you have access to the private key then you will be able to find out the session key and decrypt the traffic.

The Wikipedia TLS page explains this well:

In order to generate the session keys used for the secure connection, the client encrypts a random number with the server's public key and sends the result to the server. Only the server should be able to decrypt it, with its private key.

Wrong, see Diffie-Hellman

Posted Jan 8, 2011 20:46 UTC (Sat) by kleptog (subscriber, #1183) [Link]

Well, the GP poster is correct, if Diffie-Hellman is enabled in SSL then you have perfect forward secrecy. In other words, even if someone has the private key and sniffs all the traffic, they *still* can't decrypt it.

http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_e...

It's a neat trick whereby the server and client can agree on a key over an insecure channel.

So this list is useful for MITM attacks but not always useful for eavesdropping. Now, if they have checked all these routers and confirmed that in fact DH is disabled by default, then we have a different problem indeed.

(Incidently, I just tried my own router and Firefox doesn't say whether DH is enabled or not. Maybe that means no.)

For the fun of it, try surfing the web and rejecting any SSL connections that don't use DH. You'd be surprised the number of sites that either (a) are incompetent or (b) want anyone who has the private to be able to sniff your traffic. There are a lot of sites which will accept DH if you ask for it but will default to no.

Default "secrets"

Posted Jan 6, 2011 15:07 UTC (Thu) by jldugger (guest, #57576) [Link]

SSL encrypts both directions of traffic. The first part of this is to establish the identities, usually of the server (the client generally uses a login form to establish their identity). Without SSL encrypting all traffic, someone could potentially steal your session and submit forms on your behalf, ala firesheep.