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>
