[openssl-users] OpenSSL performance issue

[Jakob Bohm]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mta.opensslfoundation.net/pipermail/openssl-users/attachments/20141219/6fbe42c7/attachment.html>