cURL
Haxx ad
libcurl

curl's project page on SourceForge.net

Sponsors:
Haxx

cURL > Mailing List > Monthly Index > Single Mail

curl-tracker mailing list Archives

[ curl-Bugs-3017604 ] curl https post - slow with SSLv3 or TLS, but not with SSLv2

From: SourceForge.net <noreply_at_sourceforge.net>
Date: Fri, 9 Jul 2010 02:20:13 +0000

Bugs item #3017604, was opened at 2010-06-17 14:06
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3017604&group_id=976

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: SSL/TLS
Group: wrong behaviour
>Status: Closed
Resolution: Invalid
Priority: 5
Private: No
Submitted By: Marco Wotschadlo (wotschie)
Assigned to: Daniel Stenberg (bagder)
Summary: curl https post - slow with SSLv3 or TLS, but not with SSLv2

Initial Comment:
I'm having a Windows XP SP3 client, Windows Server 2003 SP2 and precompiled "curl 7.20.1 (i386-pc-win32) libcurl/7.20.1 OpenSSL/0.9.8n zlib/1.2.5". Now
I try to upload some bigger file by using http POST with following command:

curl.exe --insecure -F file=@test.file -1 https://server/application/servlets/uploadFiles (very slow)
curl.exe --insecure -F file=@test.file -2 https://server/application/servlets/uploadFiles (fast)
curl.exe --insecure -F file=@test.file -3 https://server/application/servlets/uploadFiles (very slow)

SSLv2 is uploading at normal speed, but SSLv3/TLS is terribly slow.

In the network capture one can see, that the client side is waiting for one single "ACK" which gets delayed for about 200ms (Packet no 67,68). This does not happen for SSLv2.

---8<---
No. Time Source Destination Protocol Info
     49 0.176559 10.7.9.55 10.178.98.19 TCP [TCP segment of a reassembled PDU]
     50 0.176573 10.7.9.55 10.178.98.19 TCP [TCP segment of a reassembled PDU]
     51 0.176581 10.7.9.55 10.178.98.19 TCP [TCP segment of a reassembled PDU]
     52 0.176652 10.7.9.55 10.178.98.19 TCP [TCP segment of a reassembled PDU]
     53 0.176659 10.7.9.55 10.178.98.19 TCP [TCP segment of a reassembled PDU]
     54 0.176668 10.7.9.55 10.178.98.19 TCP [TCP segment of a reassembled PDU]
     55 0.176676 10.7.9.55 10.178.98.19 TCP [TCP segment of a reassembled PDU]
     56 0.176684 10.7.9.55 10.178.98.19 TCP [TCP segment of a reassembled PDU]
     57 0.176692 10.7.9.55 10.178.98.19 TCP [TCP segment of a reassembled PDU]
     58 0.176700 10.7.9.55 10.178.98.19 TCP [TCP segment of a reassembled PDU]
     59 0.176708 10.7.9.55 10.178.98.19 TCP [TCP segment of a reassembled PDU]
     60 0.176716 10.7.9.55 10.178.98.19 TLSv1 Application Data
     61 0.177848 10.178.98.19 10.7.9.55 TCP https > moshebeeri [ACK] Seq=139 Ack=36670 Win=65535 Len=0
     62 0.178090 10.178.98.19 10.7.9.55 TCP https > moshebeeri [ACK] Seq=139 Ack=39590 Win=65535 Len=0
     63 0.178343 10.178.98.19 10.7.9.55 TCP https > moshebeeri [ACK] Seq=139 Ack=42510 Win=64775 Len=0
     64 0.178501 10.178.98.19 10.7.9.55 TCP [TCP Dup ACK 63#1] https > moshebeeri [ACK] Seq=139 Ack=42510 Win=64775 Len=0
     65 0.178508 10.178.98.19 10.7.9.55 TCP https > moshebeeri [ACK] Seq=139 Ack=45430 Win=65535 Len=0
     66 0.178781 10.178.98.19 10.7.9.55 TCP https > moshebeeri [ACK] Seq=139 Ack=48350 Win=65535 Len=0
     67 0.394840 10.178.98.19 10.7.9.55 TCP https > moshebeeri [ACK] Seq=139 Ack=50171 Win=65535 Len=0
     68 0.395406 10.7.9.55 10.178.98.19 TCP [TCP segment of a reassembled PDU]
     69 0.395421 10.7.9.55 10.178.98.19 TCP [TCP segment of a reassembled PDU]
--->8---

Regards - Marco

----------------------------------------------------------------------

>Comment By: SourceForge Robot (sf-robot)
Date: 2010-07-09 02:20

Message:
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-06-24 21:59

Message:
i just can't see how this is something libcurl can affect. If you can find
anything in curl that points to this being the fault of curl, then by all
means tell us. If not, I would say that any slowdowns in a situation like
this exists within OpenSSL and you should thus rather take your detailed
questions and test results to that team.

----------------------------------------------------------------------

Comment By: Daniel Stenberg (bagder)
Date: 2010-06-18 14:48

Message:
As you can easily check for yourself, the curl code is IDENTICAL if SSLv2
or v3/TLS is used.

I'm not saying this can't be a problem still, but it isn't as simple as
that.

----------------------------------------------------------------------

Comment By: Marco Wotschadlo (wotschie)
Date: 2010-06-18 11:11

Message:
Could it be, that SSLv2 connections are handled different than SSLv3/TLS
inside curl? As I found this:
http://support.microsoft.com/?scid=kb%3Ben-us%3B823764&x=9&y=12

Maybe the issue is related to that?

----------------------------------------------------------------------

Comment By: Marco Wotschadlo (wotschie)
Date: 2010-06-18 10:44

Message:
Could it be, that SSLv2 connections are handled different than SSLv3/TLS
inside curl? As I found this:
http://support.microsoft.com/?scid=kb%3Ben-us%3B823764&x=9&y=12

Maybe the issue is related to that?

----------------------------------------------------------------------

You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=100976&aid=3017604&group_id=976
Received on 2010-07-09

These mail archives are generated by hypermail.

donate! Page updated November 12, 2010.
web site info

File upload with ASP.NET