RE: SSL and IPS (was RE: ssh and ids)

["Rob Shein" <shoten () starpower net>]

Moderator: The tone of this post might be a bit out of the norm. When
someone disagrees with me, and is only willing to consider that I must
either be entirely ignorant or misstating things as reasons why, I tend to
get peeved.

That said, comments inline.

> On Wed, Jun 30, 2004 at 02:28:51PM -0400, Rob Shein wrote:
> > To determine the symmetric key that results from a DH exchange, all 
> > you need is the private key of one party (provided here by 
> key escrow, 
> > as Peter Schawacker described) and the public key of the 
> other party 
> > (captured off the wire).  You then perform the same 
> calculation as the 
> > party whose private key you hold, and voila; you become a 
> third party 
> > with the symmetric key. This is exactly why private keys are so 
> > sensitive, and there's nothing miraculous about it.  The 
> same goes for 
> > any rekeys, which are also done with DH.  They aren't breaking DH, 
> > they're just taking advantage of the fact that their device 
> is, like 
> > the SSL server, a trusted device which is granted access to private 
> > keys.
>
>       I'm sorry, that's just totally bogus.  Unless you are 
> seriously misstating what you are talking about, you are 
> mixing apples and oranges.
>
>       Where you say "To determine the symmetric key that 
> results from a DH exchange, all you need is the private key 
> of one party (provided here by key escrow, as Peter 
> Schawacker described) and the public key of the other party 
> (captured off the wire)."  Are you talking about the private 
> key stored in the servers key file or are you talking about 
> the D-H exponents (which are not keys at all but might be 
> referred to as keys) which are not even stored on disk at all?
>
>       Then you go on to say: "This is exactly why private 
> keys are so sensitive."  The Diffie-Hellman exponents are 
> never even stored to disk. So, what's your point here?  It 
> sounds like you are talking about the private key, from the 
> servers key file.  The thing that bounded by these lines, in 
> OpenSSL parleyance:

Well, in truth, when I was saying "private key" I meant "private key."
Sorry if I was ambiguous there.

> -----BEGIN RSA PRIVATE KEY-----
>       :
> -----END RSA PRIVATE KEY-----
>
>       That private key?  The thing typically stored on RedHat 
> Linux systems as /etc/httpd/conf/ssl.key/server.key ?  (Yes, 
> it's not always there and yes virtual servers have them under 
> their own name, you get the point).

Oh my god!  VeriSign has been collecting all that money for all these years
just to hand out colons?!?!  Good lord, it's a scam of global proportions,
call the President.  No, I mean the private key that really does exist,
along with the certificate needed for SSL.  And it does exist, otherwise the
key exchange won't work too well...

>       Which is it?  The private RSA key from the server's 
> certificate keyfile or the Diffie-Hellman exponents.  They 
> are not related.  If it's the later, please stop incorrectly 
> referring to them as keys and explain how you are obtaining them.
>
>       To clarify my side of this discussion and insure we are 
> not mixing apples and oranges at this point, I'll refer to 
> the servers long term static key which is associated with the 
> servers signed certificate file as the servers "private RSA 
> key" so it can't be mistakenly confused with the Diffie 
> Hellman parameters.
>
>       The "secret exponents" for the Diffie-Hellman key exchange
> are not the private RSA keys from the certificates.  They are 
> large prime numbers choosen at random for each session.  The 
> D-H modulus and base (n and g) are public and advertised in 
> the certificates.  The D-H session exponents (x and y) are 
> chosen at random for each session. The two parties exchange 
> (g**x mod n) and (g**y mod n) and each then computes (k = 
> g**(x*y) mod n) which no one passively listening into the 
> channel can compute.  The value "k" is the session key.  
> Nothing from the server's private RSA key (the key from which 
> the certificate is derived) is used in the D-H transaction.
>
>       Just to be formal about this whole thing, I'll remind 
> everyone of the Diffie Hellman math (apologies to the other 
> cryptographers on this list for boring you and turning this 
> into crypto 101 hell...).
>
>       (Notation here is from Applied Crytography, OpenSSL 
> source code uses different nominclature for the variable names).
>
>       Basic Diffie Hellman Key Exchange Algorithm...
>
>       Alice (the client) and Bob (the server) agree on large 
> primes, n and g, subject to some constraints (g primative mod 

They agree on the primes.  So the primes aren't a secret, and can be known
by an IDS/IPS/whatever other trusted device.  Okay...continue on...

> n, n is a "strong" prime [i.e. (n-1)/2 is also prime], no 
> special generators, yada, yada, yada - just accept it as an 
> initialization conditions - these are static public values 
> anyways - more information is avaiable in the OpenSSL sources 
> about how these are derived and why .../crypto/dh/dh_gen.c 
> for anyone interested).
>
>       1) Alice choses a random large integer x and sends Bob
>
>               X = g**x mod n
>
>       2) Bob choses a random large integer y and sends Alice
>
>               Y = g**y mod n
>
>       3) Alice computes
>
>               k = Y**x mod n
>
>       4) Bob computes
>
>               k' = X**y mod n
>
>       With a little algebraic manipulation, you find that k' 
> == k.  That is based on:
>
>               k = Y**x mod n
>                 = (g**y mod n) ** x mod n
>                 = (g**y)**x mod n
>                 = (g**(y*x)) mod n
>                 = (g**(x*y)) mod n
>                 = (g**x)**y mod n
>                 = (g**x mod n) ** y mod n
>                 = X**y mod n
>                 = k'
>
>       So Alice and Bob now have the same number k.  At this 
> point, neither Alice nor Bob have any further use for x or y 
> and may discard them.

Ah, ah, ah...not so fast, superguy.  They MAY discard them, but they do not.
And why?  Because the very concept of SSL is built not just around
encryption, but around having a trusted third party involved to certify
(ergo, "certificate") that the server is who they say they are.  From
Netscape's rather well laid-out explanation of SSL (my comments in
parentheses between items):

------

1. The client sends the server the client's SSL version number, cipher
settings, randomly generated data, and other information the server needs to
communicate with the client using SSL. 

2. The server sends the client the server's SSL version number, cipher
settings, randomly generated data, and other information the client needs to
communicate with the server over SSL. The server also sends its own
certificate and, if the client is requesting a server resource that requires
client authentication, requests the client's certificate. 

(Note that "randomly generated data" as in the preceding paragraph
corresponds to the value "n" listed further above.)

3. The client uses some of the information sent by the server to
authenticate the server (see Server Authentication for details). If the
server cannot be authenticated, the user is warned of the problem and
informed that an encrypted and authenticated connection cannot be
established. If the server can be successfully authenticated, the client
goes on to Step 4. 

(This is why Alice and Bob don't go tossing x and y into the garbage so
freely.  If Bob changes y every time, Alice will get one of those dialog
boxes stating that there's a problem with the certificate.  Sure, Alice can
proceed anyways, but honestly, is that a good thing, according to the RFC?
Nope.)

4. Using all data generated in the handshake so far, the client (with the
cooperation of the server, depending on the cipher being used) creates the
premaster secret for the session, encrypts it with the server's public key
(obtained from the server's certificate, sent in Step 2), and sends the
encrypted premaster secret to the server. 

(By the way, I'm sure they mean "public key" when they say "public key"
above.)

5. If the server has requested client authentication (an optional step in
the handshake), the client also signs another piece of data that is unique
to this handshake and known by both the client and server. In this case the
client sends both the signed data and the client's own certificate to the
server along with the encrypted premaster secret. 

6. If the server has requested client authentication, the server attempts to
authenticate the client (see Client Authentication for details). If the
client cannot be authenticated, the session is terminated. If the client can
be successfully authenticated, the server uses its private key to decrypt
the premaster secret, then performs a series of steps (which the client also
performs, starting from the same premaster secret) to generate the master
secret. 

(And this is why Alice can't go tossing x into the garbage either, according
to the spec.  If the server will only allow those with proper certificates
to connect (as CERT does, for example, for some of their servers), then
Alice must keep y static, or else she'll be unable to authenticate.)

7. Both the client and the server use the master secret to generate the
session keys, which are symmetric keys used to encrypt and decrypt
information exchanged during the SSL session and to verify its
integrity--that is, to detect any changes in the data between the time it
was sent and the time it is received over the SSL connection. 

8. The client sends a message to the server informing it that future
messages from the client will be encrypted with the session key. It then
sends a separate (encrypted) message indicating that the client portion of
the handshake is finished. 

9. The server sends a message to the client informing it that future
messages from the server will be encrypted with the session key. It then
sends a separate (encrypted) message indicating that the server portion of
the handshake is finished. 

10. The SSL handshake is now complete, and the SSL session has begun. The
client and the server use the session keys to encrypt and decrypt the data
they send to each other and to validate its integrity. 

--------


Now, if the IPS has a copy of the same certificate as the web server, it too
can do everything that the server does to derive the shared secret, assuming
that it doesn't drop any of the packets used in the negotiation phase.  It
already has x, gets n and Y from watching the exchange, and does its own
math to derive the shared secret.  And since k, the shared secret, = Y**x
mod n, there are no further barriers to it arriving at the same conclusion
as both Alice and Bob.

  This is not new technology; this option is, and has been, in place on
several IDS products for some time now.  There have even been debates on
this very list over whether it would be better to use them, or instead to
rely on SSL accelerators like F5's BigIP boxes and put sensors behind them.
It's not a widely used IDS feature, and in my opinion it's more of a
headache than it's worth, but it exists.

In all cases, x and y are indeed saved to disk, unless I am mistaken; in
that case, something that can repeatably generate x and y is saved to disk.
This is necessary for SSL as it is used in HTTPS, which is the most likely
protocol to be examined by an IPS.  With some wanky OpenSSL implementation
being used as a private VPN to dial home, sure, you can do whatever you want
with x and y.  But in the real commercial world, with real applications, x
and y come from VeriSign or someone's internal Certificate Authority, are
saved on disk, and are indeed static for the life of the certificate
(default 1 year for VeriSign).

Everything below this (which I have snipped) is based upon the assertions
above, and are thus incorrect.  I didn't feel like typing "but x and y
aren't disposed of and recreated each time!" over and over again.


---------------------------------------------------------------------------

---------------------------------------------------------------------------