[openssl-users] OpenSSL performance issue

Jakob Bohm jb-openssl at wisemo.com
Fri Dec 19 11:19:35 UTC 2014


On 19/12/2014 12:11, Jakob Bohm wrote:
> 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.
Dave Thompson (who knows more than I do) pointed out that if this is the
SSL library included with Oracle Java, then it doesn't do that, but it does
waste time on another operation (random number generator setup),
which is the same for all handshake methods.
>
> 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.
>
If the problem is really initializing the Java secure random number 
generator,
you could probably force it to initialize earlier by simply adding Java code
that asks for one byte of cryptographically strong bits, then throws it 
away,
thus forcing the Java runtime to initialize its random number library at 
that
time (before the connection arrives).
> 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/f6034ad6/attachment-0001.html>


More information about the openssl-users mailing list