XP POSReady and TLS 1.2 - ssl

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

Related

Wrong SSL version used in Dtls handshake on HelloVerifyRequest

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.)

VB.NET Web Service connection impossible : "Could not create SSL/TLS secure channel"

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.

How does one specify a particular cipher suite for a nginx docker instance?

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

Find SSL Version after Handshake in OpenSSL

I want to find out the protocols supported by a target but the problem is that their are quite a number websites which are not supporting a particular version but when i performed handshake it was successful becz target surpassed the version that i gave and perform handshake on the supported version
[ it happened on only 1 website]
example : i passed a version :TLSVersion.TLS_1_2 but the handshake is performed using TLSv1_0 becz it is not supporting TLSVersion.TLS_1_2
Because of the above issue i want to check the version on handshake and i dont want to use scapy.ssl_tls
version = [SSL.SSLv23_METHOD,
SSL.TLSv1_METHOD,
SSL.TLSv1_1_METHOD,
SSL.TLSv1_2_METHOD]
context = OpenSSL.SSL.Context(version)
soc = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
soc.settimeout(CONNECTION_TIMEOUT)
connection = OpenSSL.SSL.Connection(context,soc)
connection.connect((host,port))
connection.do_handshake()
#wants to check version here
i want to check the version on handshake
The relevant functions to check the version both client and server use for the remaining session in pyOpenSSL are get_protocol_version_name or get_protocol_version:
connection.do_handshake()
#wants to check version here
print(connection.get_protocol_version_name())
Note that these functions are only available since pyOpenSSL 0.16.0
Please not also that you cannot specify a list of TLS methods when creating the context but only a single method which essentially specifies the minimal TLS version supported by the client. Thus
context = OpenSSL.SSL.Context(SSL.TLSv1_METHOD)
allows the client to use TLS 1.0 and better. If you instead use SSL.TLSv1_2_METHOD the client would be restricted to TLS 1.2 and better and thus could not establish a SSL connection with a server supporting only TLS 1.0.
Find SSL Version after Handshake in OpenSSL...
If I am parsing what you want correctly... you want the protocol version like printed by openssl s_client:
$ openssl version
OpenSSL 1.1.0b 26 Sep 2016
$ openssl s_client -connect www.google.com:443 -servername www.google.com
CONNECTED(00000005)
depth=2 C = US, O = GeoTrust Inc., CN = GeoTrust Global CA
verify error:num=20:unable to get local issuer certificate
Server did acknowledge servername extension.
---
...
---
New, TLSv1.2, Cipher is ECDHE-RSA-CHACHA20-POLY1305
Server public key is 2048 bit
Secure Renegotiation IS supported
No ALPN negotiated
SSL-Session:
Protocol : TLSv1.2
...
The first message of "New, TLSv1.2" tells you about the cipher. That is, when is ECDHE-RSA-CHACHA20-POLY1305 first arrived in TLS. In the case of ECDHE-RSA-CHACHA20-POLY1305, the cipher suite was first seen in TLS 1.2.
The source code for s_client is located at <openssl src>/apps/s_client.c. The code responsible in OpenSSL 1.0.2 is around line 2210:
/* line 2210 */
c = SSL_get_current_cipher(s);
BIO_printf(bio, "%s, Cipher is %s\n",
SSL_CIPHER_get_version(c), SSL_CIPHER_get_name(c));
...
The second message of "Protocol: TLSv1.2" tells you the protocol version used during key exchange and subsequent cipher selection and bulk transfer.
The code responsible in OpenSSL 1.0.2 is <openssl src>/ssl/ssl_txt.c around line 105:
/* line 105 */
int SSL_SESSION_print(BIO *bp, const SSL_SESSION *x)
{
unsigned int i;
const char *s;
if (x == NULL)
goto err;
if (BIO_puts(bp, "SSL-Session:\n") <= 0)
goto err;
if (x->ssl_version == SSL2_VERSION)
s = "SSLv2";
else if (x->ssl_version == SSL3_VERSION)
s = "SSLv3";
else if (x->ssl_version == TLS1_2_VERSION)
s = "TLSv1.2";
else if (x->ssl_version == TLS1_1_VERSION)
s = "TLSv1.1";
else if (x->ssl_version == TLS1_VERSION)
s = "TLSv1";
else if (x->ssl_version == DTLS1_VERSION)
s = "DTLSv1";
else if (x->ssl_version == DTLS1_2_VERSION)
s = "DTLSv1.2";
else if (x->ssl_version == DTLS1_BAD_VER)
s = "DTLSv1-bad";
else
s = "unknown";
if (BIO_printf(bp, " Protocol : %s\n", s) <= 0)
goto err;
...
}
I want to find out the protocols supported by a target but the problem is that their are quite a number websites which are not supporting a particular version but when i performed handshake ...
This is a different problem. You should look at the source code for sslscan at SSLScan - Fast SSL Scanner to see how it works. The Sourceforge one seems abandoned. It lacks SNI and other new features, like secure negotiation and ALPN.
You might try this sslscan from GitHub: rbsec/sslscan. The GitHub one is actively maintained and seems to be more up to date.
example : i passed a version :TLSVersion.TLS_1_2 but the handshake is performed using TLSv1_0 becz it is not supporting TLSVersion.TLS_1_2
This will not happen. TLS specifies one protocol version only. The idea is your try TLS 1.2. If it fails, then you fall back to TLS 1.1. If it fails, then you fall back to TLS 1.0. Ad infinitum.
The try-and-fallback approach is the reason for RFC 7504, TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks. This was an awful band-aide from the Browser crowd. See, for example, Last Call: <draft-ietf-tls-downgrade-scsv-03.txt> (TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks) to Proposed Standard.
TLS does not accept a range of protocol versions like many folks think. We have tried to get it changed a few times. See, for example, A new TLS version negotiation mechanism.

SSLv2 client getting TCP RST from stud

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.