At least I think stud is the culprit.
My server setup is stud -> haproxy -> nginx -> express server
Requests don't make it through to haproxy.
I make a request with SSLv2:
import httplib
c = httplib.HTTPSConnection("my-server.com")
c.request("GET", "/foo/bar")
response = c.getresponse()
print response.status, response.reason
data = response.read()
print data
... and get back
socket.error: [Errno 54] Connection reset by peer
Here's the SSL dump:
New TCP connection #1: clientIP(29779) <-> my-server.com(443)
1 1 0.0044 (0.0044) C>S SSLv2 compatible client hello
Version 3.1
cipher suites
TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
Unknown value 0x9a
Unknown value 0x99
Unknown value 0x96
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_RC4_128_MD5
Unknown value 0xff
1 0.0047 (0.0002) S>C TCP RST
Does anyone have any idea how to get stud to accept SSLv2 requests?
Thanks
Obviously the haproxy doesn't support SSLv2, but even if it did it, is practically certain that the target server won't support it either.
Your requirement is 20 years out of date. Java for example has never supported SSLv2, except in the IBM JVM, and I doubt that it still does there.
Educate the client.
Related
I am implementing DTLS 1.2 protocol in C. While testing the client with openSSL, I observed that one of the frames sent by OpenSSL is not using the correct Dtls version (1.2) but an older version (1.0).
The client in C supports only DTLS1.2, and therefore reject the frame send by OpenSSL.
HelloClient sent by the C client:
Frame 2461: 109 bytes on wire (872 bits), 109 bytes captured (872 bits) on interface 0
Ethernet II, Src: Infineon_00:00:01 (00:03:19:00:00:01), Dst: Tp-LinkT_dc:4e:82 (50:3e:aa:dc:4e:82)
Internet Protocol Version 4, Src: 192.168.88.73, Dst: 192.168.88.77
User Datagram Protocol, Src Port: 50003, Dst Port: 60003
Datagram Transport Layer Security
DTLSv1.0 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: DTLS 1.2 (0xfefd)
Epoch: 0
Sequence Number: 0
Length: 54
Handshake Protocol: Client Hello
Response from OpenSSL server:
Frame 2464: 90 bytes on wire (720 bits), 90 bytes captured (720 bits) on interface 0
Ethernet II, Src: Tp-LinkT_dc:4e:82 (50:3e:aa:dc:4e:82), Dst: Infineon_00:00:01 (00:03:19:00:00:01)
Internet Protocol Version 4, Src: 192.168.88.77, Dst: 192.168.88.73
User Datagram Protocol, Src Port: 60003, Dst Port: 50003
Datagram Transport Layer Security
DTLSv1.0 Record Layer: Handshake Protocol: Hello Verify Request
Content Type: Handshake (22)
Version: DTLS 1.0 (0xfeff)
Epoch: 0
Sequence Number: 0
Length: 35
Handshake Protocol: Hello Verify Request
I force OpenSSL to use the version 1.2 of DTLS running the following command:
openssl.exe s_server -nocert -psk 01234567 -accept 443 -cipher PSK-AES128-GCM-SHA256 -dtls1_2
I saw in the RFC of TLS (https://www.rfc-editor.org/rfc/rfc5246#appendix-E)
TLS versions 1.0, 1.1, and 1.2, and SSL 3.0 are very similar, and use
compatible ClientHello messages; thus, supporting all of them is
relatively easy. Similarly, servers can easily handle clients trying
to use future versions of TLS as long as the ClientHello format
remains compatible, and the client supports the highest protocol
version available in the server.
Nothing is specified for HelloRequestVerify (rfc5246 or rfc6347), but does that means that any version between 1.0 and 1.2 should be accepted?
Or is that a bug in OpenSSL?
Note: If I continue the DTLS handshake, every further frame sent by OpenSSL are using the correct version of DTLS (1.2).
According RFC 6347, 4.2.1. Denial-of-Service Countermeasures
However, in order to avoid the requirement to do version negotiation
in the initial handshake, DTLS 1.2 server implementations SHOULD use
DTLS version 1.0 regardless of the version of TLS that is expected to
be negotiated.
(That section contains some more information on that usage.)
I'm trying to use TLS 1.2 on Windows XP POSReady after having installed the Microsoft released KB4019276 - https://support.microsoft.com/en-us/help/4019276/update-to-add-support-for-tls-1-1-and-tls-1-2-in-windows) and enabled it in registry.
My very simple code to test it is :
Option Explicit
Const WinHttpRequestOption_SecureProtocols = 9
Const SecureProtocol_SSL2 = 8, SecureProtocol_SSL3 = 32, _
SecureProtocol_TLS1 = 128, SecureProtocol_TLS1_1 = 512, _
SecureProtocol_TLS1_2 = 2048
Dim objHTTP
Set objHTTP = CreateObject("WinHttp.WinHttprequest.5.1")
objHTTP.open "GET", "https://www.howsmyssl.com/a/check", False
objHTTP.Option(WinHttpRequestOption_SecureProtocols) = SecureProtocol_TLS1_2
objHTTP.Send
If objHTTP.WaitForResponse(30) Then 'wait up to 30 seconds
WScript.Echo "Status : " & objHTTP.Status & "<br />"
WScript.Echo "Response Length : " & LenB(objHTTP.ResponseBody)
WScript.Echo "Response Text : " & objHTTP.ResponseText
Else
WScript.Write "Request timed out"
End If
Set objHTTP = Nothing
but anything over TLS 1.0 is giving me the error :
Invalid argument for Option
while, disabling SSL 2.0, SSL 3.0 and TLS 1.0 I'me getting an error about not being able to negotiate a security protocol.
any advice ?
Thank you.
IF actually have the same problem on my expermiental Winxp sp3 (all further updates included).
I found out that WINHTTP.DLL does still not contain the API Call function
SECUREPROTOCOL_TLS1_1 as well as SECUREPROTOCOL_TLS1_2.
Causing the "invalid option" error.
So, this syntax isn't supported on standard XP systems !
(winhttp.dll not getting updated). ONly embeddedXP might have optained an updated winhttp.dll file accepting this option.
I now make efforts to somehow obtain the updated ominous winhttp.dll.
Results will be reported here.
Here is what ssllabs client test looks like after applying KB4019276
Protocols
TLS 1.3 No
TLS 1.2 Yes*
TLS 1.1 Yes*
TLS 1.0 Yes*
SSL 3 Yes*
SSL 2 No
Cipher Suites (in order of preference)
TLS_RSA_WITH_AES_256_CBC_SHA256 (0x3d) WEAK 256
TLS_RSA_WITH_AES_128_CBC_SHA256 (0x3c) WEAK 128
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) WEAK 256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) WEAK 128
TLS_RSA_WITH_RC4_128_MD5 (0x4) INSECURE 128
TLS_RSA_WITH_RC4_128_SHA (0x5) INSECURE 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) WEAK 112
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (0x6a) WEAK 256
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (0x40) WEAK 128
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x13) WEAK 112
Protocol Details
Server Name Indication (SNI) No
Secure Renegotiation Yes
TLS compression No
Session tickets No
OCSP stapling No
Signature algorithms SHA256/RSA, SHA384/RSA, SHA1/RSA, SHA1/DSA, SHA512/RSA
Named Groups -
Next Protocol Negotiation No
Application Layer Protocol Negotiation No
SSL 2 handshake compatibility No
There are no ECDHE negotiating cipher suites so everything is deemed WEAK or outright INSECURE.
Folks. The relevant Update for enabling TLS 1.2 in XP has been re-released
as of 18 Feb 2018. (KB4019276). Downloaded from the MS UpdateCatalog.
This is a correction for the (obviously buggy) initial release in October 2017.
Which now WORKS correctly !
Features in IE8 : TLS 1.2 enabled
included also : TLS Session Ticket support
NEW available Suites (howsmyssl.com, ssllabs):
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b) FS 128
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f) FS 128
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca9) FS 256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 (0xcca8) FS 256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA (0xc00a) FS 256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA (0xc009) FS 128
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) FS 128
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) FS 256
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) FS 128
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) FS 256
Supported Named groups for EC : secp256r1, secp384r1, secp521r1
Kind Regards!
BerndP
I am trying to connect to a web service which is written in Java language on the server side. My program is written in VB.NET 4.0 on the client side.
When i try to call any methods from the web service I receive the following error message :
WS-Metadata Exchange Error URI: [http://...] Metadata contains a reference that cannot be resolved. The request was aborted: Could not create SSL/TLS secure channel
I am using a certificate to connect to the web service, however it seems that the problem is on the communication level between my host machine (client) and the server. The certificate i am using is never been checked as the client and the server can even not communicate.
I have tried to set the security protocol to "SSLv3" or "TLS12" but it didn't help. Thank you in advance for any suggestions.
Also i should mention that i managed to connect to this web service using a Java class. It seems that when the client side is written in Java it works but when it's in VB.NET it doesn't work.
P. HAB
EDITED :
I used "Wireshark" to discover the HTTPS packets which are sent and received by my program, here what I found in the transmitted packets :
Request by the client :
Secure Sockets Layer
TLSv1 Record Layer: Handshake Protocol: Client Hello
Content Type: Handshake (22)
Version: TLS 1.0 (0x0301)
Length: 140
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 136
Version: TLS 1.0 (0x0301)
Random
Session ID Length: 0
Cipher Suites Length: 24
Cipher Suites (12 suites)
Compression Methods Length: 1
Compression Methods (1 method)
Extensions Length: 71
Extension: server_name
Extension: elliptic_curves
Extension: ec_point_formats
Extension: Extended Master Secret
Extension: renegotiation_info
Response from the server :
Secure Sockets Layer
TLSv1 Record Layer: Alert (Level: Fatal, Description: Handshake Failure)
Content Type: Alert (21)
Version: TLS 1.0 (0x0301)
Length: 2
Alert Message
Level: Fatal (2)
Description: Handshake Failure (40)
I have tried to change the security protocol to different versions of SSL/TLS but it changed nothing. My client tries to send a "Client hello" with standard values (no user-customized parameters were specified) but the server is not accepting it. Any suggestions ?
Solution found :
The problem is in fact related to the Cipher suites and specially the RC4 algorithme. Actually my client is written in VB.NET 4.0 and in this version of .NET the deprecated RC4 algorithme is still supported and proposed by the .NET framework to any Web server during the "Hello Client" (Handshake) process.
The only presence of the RC4 cipher suites in the supported list of the cipher suites by my client was making the server to abort the connection with the following error message : "The request was aborted: Could not create SSL/TLS secure channel"
So I had to deactivate the RC4 cipher suites on my client machine by going in the system registry using regedit.exe and add the following key to these two specified paths :
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319
"SchUseStrongCrypto"=dword:00000001
And
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v4.0.30319
"SchUseStrongCrypto"=dword:00000001
After restarting the client machine I was able to connect to the web service succesfully.
For more information about the deprecated RC4 algorithmes :
https://technet.microsoft.com/en-us/library/security/2960358.aspx
=> Also you should notice that this problem exists only in .NET 4.0-4.5. From the version 4.6 and above its working fine.
I am running a newly built discourse docker image on Google Compute Engine. I converted that to use https using letsencrypt following the walk through and I get an A+ rating from ssllabs. However the scripting agent I'm using doesn't support either of the two TLS 1.0 cipher suites enabled [TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA, TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA] and I'd like to add TLS-DHE-RSA-WITH-AES-256-CBC-SHA which is supported by the open source rebol3 fork ren-c.
I've modified my web.ssl.template.yml file from
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:\
ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:\
ECDHE-RSA-AES256-SHA;
to
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:\
ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:\
ECDHE-RSA-AES256-SHA:TLS-DHE-RSA-WITH-AES-256-CBC-SHA;
and rebuilt the app using
sudo ./launcher rebuild app
but this doesn't alter the cipher_suites available.
I'm now wondering if I have to alter the nginx.conf directly, wherever that is, instead of asking the discourse build script to do it ...
Changing the line in /var/discourse/templates/web.ssl.template.yml
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:\
ECDHE-RSA-AES128-SHA256$RSA-AES256-SHA384:ECDHE-RSA-AES256-SHA;
to
ssl_ciphers 'HIGH:!aNULL:!MD5';
changes the supported TLS 1.0 suites to
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp384r1 (eq. 7680 bits RSA) FS 256
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84) 256
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp384r1 (eq. 7680 bits RSA) FS 128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41)
and still gives an A+ rating from ssllabs.
mkdir -p containers/templates
cp templates/web.ssl.template.yml containers/templates
fuss with the file
add containers/templates/web.ssl.template.yml to you app.yml file in the templates section
profit
Setup :
Erlang cluster with two Erlang nodes, different names, identical SSL setup (certificates, keys, authority)
the two nodes are listening for connections on the same port
the accept scheme is simple and doesn't have an acceptor pool in front : ListenSocket = ssl:listen() when the app starts -> then, in the children, I do AcceptSock = ssl:transport_accept(ListenSocket) + ssl:ssl_accept(AcceptSock) + mysup:start_child() which will start a new gen_server to listen on ListenSocket (in the gen_server init() I have timeout == 0, btw - to make the gen_server receive a timeout message which will be handled with handle_info(timeout...) which does the accept scheme above).
Expected behavior :
I expect all of this to work all the time :)
Observed behavior :
from time to time, one or both servers stop accepting ssl connections from the iOS apps. telnet to that port works - and it even passes transport_accept().
from the iOS app, I get a "SSLHandshake failed, error -9806" and it doesn't look like transport_accept() was successful (I have error logging before and after that line and I do not see any error messages printed in the log - theoretically, it looked like the iOS app is not trying to connect to that port, but it did try, because it says SSLHandshake failed).
I followed this thread - and got the followings :
openssl s_client -connect myserver:4321 -servername myserver -ssl3 -tls1 -prexit
CONNECTED(00000003)
write:errno=60
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 0 bytes and written 0 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol : TLSv1
Cipher : 0000
Session-ID:
Session-ID-ctx:
Master-Key:
Key-Arg : None
Start Time: 1460057622
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
same command executed with the second server (that is still accepting connections) returned a lot more infos and doesn't time out.
Any help is appreciated, thank you.