X-Recipient: archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status: No, hits=-2.4 required=5.0	tests=AWL,BAYES_20,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,KHOP_RCVD_TRUST,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE
X-Spam-Check-By: sourceware.org
X-Received: by 10.204.150.218 with SMTP id z26mr33473322bkv.95.1357679103283;        Tue, 08 Jan 2013 13:05:03 -0800 (PST)
Message-ID: <50EC89FD.8050702@gmail.com>
Date: Tue, 08 Jan 2013 22:05:01 +0100
From: doesniedoen <doesniedoen AT gmail DOT com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: Problem with HTTPS in LWP module in Perl - solution
In-Reply-To: <CAKChYSqz8PXYhF3azLRVe=BcAQOC1ZnwzjLAxn7EWw-qKn398w at mail dot gmail dot com>
References: <CAKChYSqz8PXYhF3azLRVe=BcAQOC1ZnwzjLAxn7EWw-qKn398w AT mail DOT gmail DOT com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

FYI,

I ran into the same problem, did some wiresharking, and  figured out 
what the differences are
between a successful handshake (Firefox) and the failure (LWP using 
SSLeay/openssl).
I'm not too familiar with SSL/TLS etc, but it turns out that the cipher 
list is way larger using
openssl (64 suites) than with Firefox (36 suites). I figure the order 
and presence of some ciphers
is the cause: the actual cipher used is TLS_RSA_WITH_RC4_128_SHA, which 
is present in both
cases. Also the TLS version used (1.0 for Firefox, 1.2 for openssl) does 
not make a difference.

The following code allows for a successful transaction with 
https://www.geocaching.com.
The solution is in the SSL_cipher_list:

$ perl -e '$ENV{PERL_NET_HTTPS_SSL_SOCKET_CLASS}="IO::Socket::SSL";\
use IO::Socket::SSL; IO::Socket::SSL::set_defaults(SSL_cipher_list => 
"RC4-SHA");\
use LWP::UserAgent; print LWP::UserAgent->new()->request(\
HTTP::Request->new(GET=>"https://www.geocaching.com"))->content;'

However this includes only the one cipher (and 
TLS_EMPTY_RENEGOTIATION_INFO_SCSV).

Expanding to all SHA ciphers, the following filter must be used:
           'SHA:!NULL:!3DES:!DES:!ADH:!SRP'

Finally, this is the filter with a relatively broad scope, and again all 
exclusions are required:

          'ALL:!3DES:!DES:!ADH:!SRP:!AESGCM:!SHA256:!SHA384'

When any of these excluded ciphers/hashes are present in the Client 
Hello negotiation packet,
there is no response from the server besides a TCP ACK.
Note that, for instance, '!3DES' also filters out ciphers that use 3DES 
as an encoding (I guess)
and not as the main cipher, such as TLS_RSA_WITH_3DES_EDE_CBC_SHA, who's 
presence in the handshake is not problematic.

I figure that servers that do not respond at the TLS/SSL level when they 
see a client offering certain capabilities have their reasons for doing 
so, for a 'rep scasw' can't be that buggy.

Yours sincerely,
   Kenney Westerhof


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple