On 19/12/2014 00:10, Prabhat Puroshottam wrote:
I am trying to summarize the problem again, since the previous
mail seems confusing to some of you. It might help you quickly understand
the problem I am facing:
We have a product, where Client connects to Server (Proxy Server in my
earlier mail). Client is implemented in C and uses OpenSSL, while Server is
implemented using Java code with BufferedInputStream and
BufferedOutputStream. The following are my observations:
1. There is "inordinate" delay during connection establishment.
2. Using ssldump it was found that SSL handshake response from Server is
taking most of the time. Rest of the application data transfer and
processing hardly takes fraction of a second. The response from SSL
handshake by Server comes after anywhere between 2 to 13 seconds
after initial response sent by Client.
3. Subsequent analysis of the code showed that it was the first Buffered
Read/Write which was taking "inordinate" amount of time.
4. Understanding that first Buffered Read/Write was hung on SSL connection
completion, I introduced SSLConnect::startHandshake() so that I can
explicitly see where is the problem. It was observed that now
startHandshake() blocked for as much time as first Read/Write did.
Further none of the Read/Write calls block, and returned data almost
immediately.
I would like to understand why startHandshake() is taking so long. I
understand that it is a asynchronous call, but still the time delay is too much
IMO. Is it something to do with the socket configuration/cipher/encryption
used? Using ssldump I found there was absolutely no data transfer
between the sending of client's hello request and subsequent response
from server, so apparently all the time startHandshake() is busy doing
something or may be nothing - what I have no idea. FWIW, this is not a
network latency issue, 1) all the boxes are on the same network, 2) all
other data transfers combined takes less than 0.4s.
Can somebody kindly suggest what might be wrong or what can be done to
fix this? Could it be some Socket or SSL setting, encryption/cipher used, or
something else?
From the traces in your previous questions, and the answers you have
already
given, I guess this is what happens:
1. The difference is in how long the Java code spends during the initial key
exchange.
2. The SSL code in the proxy, (but not the one in your own server) is
configured
to support Ephemeral Diffie-Hellman (DHE) handshake, which is safer, but
potentially slower. The slowness of DHE happens only during the
handshake,
because the data transmission part is the same. For example
RSA_AES256_SHA256 and DHE_RSA_AES_SHA256 use the same transmission
phase, but different handshakes. The safety of DHE is that it
protects you
if someone "tapes" the encrypted connection and later steal the private
key of the proxy/server.
3. The slowest part of doing a DHE exchange is choosing a (non-secret)
prime,
which can be used again and again for many connections. This is only done
by the server end of a TLS/SSL connection. The prime (and a few related
numbers is known as the "DH group parameters".
4. If you were to enable DHE in an OpenSSL based server/proxy, the standard
solution is to choose the non-secret prime during server startup,
before any
connection arrives. Some programs even choose it while configuring the
server program, storing the prime in a file.
5. From the long time spent by the Java code generating its ServerHello, I
suspect it is generating the prime during the handshake, and choosing a
new prime for each connection, thus wasting a lot of time.
6. Maybe there is a way to tell the Java SSL library to generate the DH
group parameters for needed key lengths (1024, 2048 or whatever you
need) during proxy startup, so it is ready by the time the client
connects.
7. If you upgrade to OpenSSL 1.0.1 or later (remember to only use the
latest letter-suffix security update of whatever version), you could also
use an ECDHE_RSA_xxx crypto mode, these don't currently allow the
server/proxy to generate their own group parameters, but force you
to choose from a short list of parameters generated by professional
spying agencies such as the NSA (the "NIST curves") or someone else
(the "X9.62 curves", the "SECG curves" and the "WTLS curves"). So
your computers don't spend time generating the parameters, and
you just have to trust the professionals who chose them for you.
Enjoy
Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
_______________________________________________
openssl-users mailing list
openssl-users@openssl.org
https://mta.opensslfoundation.net/mailman/listinfo/openssl-users
