In https://bugzilla.mozilla.org/show_bug.cgi?id=472975 georgi said in comment 12:
offtopic question: afaict when doing a ssl connection, the server *doesn't sign* anything with his private key (in most cases). though the server needs it for finding the session secret. are attacks with symmetric ciphers studied like: the server gives a valid cert trying to impersonate something. he doesn't have the private key but tries to ``break'' the symmetric ciphers - advertising null cipher, very short key length of the cipher? i tried something like this but firefox didn't accept null ciphers and gave error. is it possible the server to make symmetric keylength say 8 bits and the client to accept it (afaict some ciphers allow variable keylength)?
I'm moving this to dev-tech-crypto mailing list, since it doesn't belong in the bug, but I did want to make sure georgi gets the answer.First the short answer: 1) breaking one of the weak symmetric encryption keys (there are a couple) will not allow you to use a certificate that you don't have the private key for.
2) you can only force a weak symmetric cipher if the client allows it. IIRC
we have turned off weak ciphers in the newest versions of firefox by default
(though you can turn them back on again if you want).
-----------------------------
Long answer:
There are several symmetric keys involved in an SSL connection. They are:
1) The pre-master secret - this is a 48 byte (384 bit) key negotiated between
the client and server for RSA ciphers that means the client picks it and sends
it to the server encrypted with the server's public key. Knowledge of this key
will essentially give you the ability to spoof either or both sides of the SSL
connection. It will also allow you make more connections to either the client
or the server until either of them decide that they need to do a full handshake
(this usually happens if one side has forgotten the master secret, or the
lifetime of the master secret has expired -- usually 24 hours in SSL3/TLS).
2) Master secret - this is also a 48 byte (384 bit) key which is derived from
the pre-master secret. Unless the Hashing functions are completely broken (and
in this respect neither MD-5 nor SHA-1 have shown any weaknesses), you cannot
get to the pre-master secret from the master secret, however from an attacker
point of view, it doesn't matter. Getting the Master secret is sufficient to
control the connection in the same way as getting the pre-master secret.
3) Session keys. There are 4 session keys used in a single ssl connection.
These keys are generated from the master secret and two public random numbers,
one provided by the client and one provided by the server. Since both provide
random numbers, it's not possible for one side to force the same session keys
in a second connection. This means as long as the prf is strong, you cannot use
the breaking of one of these session keys to either 1) break the master secret,
2) extend the knowledge to a future session, or 3) break the rest of the keys.
The 4 session keys are:
3a) Server write macing key - 16-20 bytes (or 128-160 bits) depending
on MD5 or SHA-1 macing
Breaking this key is required in order to complete an SSL connection from
the server side.
3b) Client write macing key - 16-20 bytes (or 128-160 bits) depending
on MD5 or SHA-1 macing
Breaking this key is required in order to complete the SSL connection from
the client side.
3c) Server write key - 0 - 32 bytes (or 0 - 256 bits) depending on the
symmetric algorithm.
Breaking this key is required in order to read the server's data.
3d) Client write key - 0 - 32 bytes (or 0 - 256 bits) depending on the
symmetric algorithm.
So if your goal is to use someone else's certificate, you will need to either
1) break the pre-master secret, 2) break the master secret, or 3) break both
the server write macing key and the server write key. Even if you you can
force a client to choose weak or NULL ciphers, you still have to break the
macing key.
To compound this, the client only generates data using it's own write and write
macing keys. It knows the servers keys, but only validates data. At the end of
the initial handshake the server has no information with which to attack it's
own write keys, it can only know it it's guess is correct by asking the client.
The client only gives the server one shot and it fails the connection. This
means, in order to implement your attack you must either break the pre-master
secret* (basically attacking RSA), or the master secret (basically attacking
one of the client keys, and then attacking the derive function to get the
master secret).
Finally, as mentioned above, as encryption supported generally in the internet
gets stronger, clients drop support for weaker ciphers. You have already
noticed FF does not support null ciphers by default. The same is true of 'weak'
ciphers like the old export ciphers.
Hope this helps, the complexity of the SSL protocol is because it protects
against so many different kinds of attacks, including this one.
bob
*There was an attack against the pre-master secret discovered by Blechenbaucher, which required using the real server as an oracle, giving it several slightly modified versions of a real encrypted pre-master secret and noting the differences in the types of errors it returned. Modern SSL servers do not provide this kind of detailed knowledge, much to the chagrin of may SSL implementers trying to debug their code. Unfortunately such lack of response is necessary for the security of the system as a whole.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
