Hello,
I'm currently auditing an application (my own) and have come up with a
question I cannot answer: how secure is a TLS session?
The app is the server side of a client-server communication protocol
using TLS. The socket is provided by socat, which I have configured to
delegate encryption to OpenSSL in FIPS mode. The server has a 2048-bit
RSA key. Everything is working fine.
On the client I can see that the negotiated ciphersuite is
TLS_RSA_WITH_AES_128_CBC_SHA.
My intent was to send a 256-bit key to the server app (used for other
purposes within the server) over this link. Of course, encrypting this
with the negotiated 128-bit AES key weakens it, so my initial instinct
was to simply limit the ciphersuites on the server to
TLS_RSA_WITH_AES_256_CBC_SHA.
However...
Would this make any difference at all? The RSA key used to send the
pre-master secret in the TLS handshake is a 2048-bit key, which is
generally considered to provide 112 "bits of security" (see table 2, p.
63 of NIST Special Publication 800-57 at
http://csrc.nist.gov/publications/nistpubs/800-57/sp800-57-Part1-revised2_Mar08-2007.pdf)
The way I understand TLS, this pre-master secret is used to generate
the AES key.
It seems to me that regardless of the AES key strength selected, the TLS
session itself is limited 112-bit security by the 2048-bit RSA key. Am
I missing something here?
And if this is the case, any suggestions for ways to improve this short
of using a 15360-byte RSA key (which is not feasible for this application)?
Thanks,
Marty Lamb
______________________________________________________________________
OpenSSL Project http://www.openssl.org
User Support Mailing List openssl-users@openssl.org
Automated List Manager [EMAIL PROTECTED]
