Trying connect to https server (https://3dsecure.kkb.kz) using TLS 1.2.
(defn- http-request-clojure [xml req-type]
(let [url-info (url-map req-type)
(prepare-response (.toString (:body (client/get
(str (:url url-info) "?"
(and (:name url-info)
(str (:name url-info) "="))
(URLEncoder/encode xml))
{:insecure? true
:socket-timeout 10000
:conn-timeout 10000}))))))
Got error "javax.net.ssl.SSLException: Received fatal alert: protocol_version"
openssl 1.0.1g , java 7.
Any ideas what goes wrong?
It's not you, it's them: from their Qualys SSL Labs report:
Java 6u45 No SNI 2 Protocol or cipher suite mismatch Fail3
Java 7u25 Protocol or cipher suite mismatch Fail3
Java 8u31 TLS 1.2 TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) No FS 112
at least from today. They could fix this at any time, so hopefully you have a close enough relationship to politely encourage them to folow that link, and perhaps update openssl to they aren't vulnerable to this protocol downgrade attack.
This is almost always a simple matter of changing the nginx or apache config, though it can take a little fiddling to ensure all devices can still connect. SSL labs is an amazing resource for figuting this out.
From your perspective, is using Java 8 an option? It will be the easiest way past this.
Related
We are currently using java 7 and have trouble connecting to the geocode API from HERE.
When testing in our application we receive an error as follows:
Received fatal alert: handshake_failure
The url we request:
https://geocoder.ls.hereapi.com/6.2/geocode.json?apiKey={API-KEY}&searchtext=NYC,+USA
Running the same request in Postman works seamlessly.
Likewise running the code for the request in an alternative java 8 workspace. The request returns the expected response.
We assume the reason is that no matching ciphers exist between client and server when using java 7.
Does the HERE support team know of problems similar to this?
Is there a good workaround without having to upgrade to jdk1.8?
The HTTP connection to HERE APIs utilizes via TLSv1.2 cryptographic protocol because TLSv1.0 and TLSv1.1 have known security vulnerabilities.
In the jdk1.8 the SSLContext has been already set to TLSv1.2 by default therefore it works (unlike jdk1.7, you can see a handshake info if pass the -Djavax.net.debug=all parameter).
For java 7 you need to set SSLContext to TLSv1.2 before a https connection to init in your java code:
SSLContext sslCtx = SSLContext.getInstance("TLSv1.2");
sslCtx.init(null,null,null);
SSLContext.setDefault(sslCtx);
Additionally you can update the Unlimited Strength Java(TM) Cryptography
Extension (JCE) Policy Files for the Java(TM) Platform, Standard
Edition (Java SE) Runtime Environment 7 - This bundle provides "unlimited strength" policy files which contain no
restrictions on cryptographic strengths.
We are using one server which is currently gone through TLS 1.2 up-gradation.
Before that, our one tool which is communicating to server via gsoap works fine. Now I am getting SSLv3 alert handshake failure in soap_connect method. More precisely under soap->fopen method. I have also added certificate with for soap_ssl_client_context passing with SOAP_SSL_DEFAULT parameter and also tried with other parameters but no luck.
Can you please help me regarding to it?
I observed that I am using OpenSSL 1.0.0e but TLS 1.2 introduced in OpenSSl 1.0.1 found in thread stackoverflow.com/questions/48178052/…. SO just upgrading OpenSSL to 1.1.1 solved my issue.
I am fairly new to Pound cfg and SSL in general and working on learning. Tried a few things I found on Google related to setting Ciphers but they failed.
We are having an issue with Firefox after setting Ciphers in Pound to not allow SSLv3. Firefox tells customers that the system is not setup properly, so it is blocking them. Here is what I am trying to do.
Disallow SSLv3, SSLv2 via Pound Cfg file. Here is what I have tried:
Ciphers "All:!SSLv2:!SSLv3"
We are using SHA2 through Godaddy for Cert and SHA256 for key. When I test via https://dev.ssllabs.com/ssltest/ we get a giant F. Any ideas?
Any and all help is greatly appreciated. Thanks!
"Ciphers" is used to configure the cipher suites, not the SSL/TLS protocols. According to the man page, you want to do this:
Disable SSLv3
Note that Disable works by disabling that protocol and all lesser protocols, so disabling SSLv3 also disables SSLv2 along with it.
You will probably want to configure Ciphers as well. Exactly how you configure it depends on what browsers and user agents you want to support, but you can get started with:
Ciphers: "EECDH+AESGCM:AES128+EECDH"
I have been a long time reader but this is my first real post on a topic that I couldn't find a solution to.
I am currently hosting a website on Windows 2012 that I would like to get the latest TLS 1.2 ciphersuites running on.
I am aware of how to enable TLS 1.1 and TLS 1.2 in windows and have done so(via registry edits). I have also changed the cipher order to what I would like it to be.
My question is: How do i actually go through and set up my ECDHE / ECDSA portion of the cipher suite after this step?
When i view the site in the latest chrome beta (which supports ECDHE and ECDSA in TLS 1.2 provided you use the supported curves) it seems to skip all of the ECHDE ciphersuites.
Is there something else i need to do to get ECDHE/ECDSA properly enabled?
I have read around on the net trying to solve this myself and they mention making copies of your root cert and then modifying them to somehow support ECDHE. Am i barking up the wrong tree?
Thank you in advance for any and all support with this issue.
Edit: adding clarification/progress
After more research, I have found that in order to get ECDSA to work, you need an ECDSA certificate. The only way to get one at this time is to self-sign, as the cert-cartel has not yet come up with proper cross-licensing agreements and fee structures for Ellipic Curve Certificates yet.
Since self-signing is not an option for this site, I have removed all ECDSA suites from the cipher-order.
Unfortunately, because all of the AES Galois Counter Mode suites were also ECDSA, this rules those out for the time being.
This leaves me with a strongest cipher suite of ECDHE_RSA_WITH_AES_256_CBC_SHA384_P521 which I BELIEVE is supported by the latest version of Chrome beta correct? I can't seem to get Chrome to pick up anything beyond SHA-1. Is there no SHA-2 support? even in the latest beta?
AES-GCM is about how you encrypt the data in your connexion, EC-DSA or RSA about how the server identifies itself to the client. There is therefore no reason why you couldn't do AES-GCM encryption with a RSA authentication.
RFC 5289 does define the needed suite for that :
https://www.rfc-editor.org/rfc/rfc5289#section-3.2
CipherSuite TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 = {0xC0,0x2F};
CipherSuite TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 = {0xC0,0x30};
CipherSuite TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 = {0xC0,0x31};
CipherSuite TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 = {0xC0,0x32};
It's not however necessarily easy to find both the client and the server that will support them.
I had similar experiences with Win2008 R2.
Depending on the certificate, GCM cipher is offered by the server or not.
With self-signed ECDSA certificate i got GCM to work but older browsers
or Windows XP can't connect to such a https-site.
Windows doesnt support any TLS_ECDHE_RSA...GCM... ciphers:
http://msdn.microsoft.com/en-us/library/aa374757(v=vs.85).aspx
Thus normal RSA-certificates don't work with GCM under Windows.
Browser compatibility:
http://www.g-sec.lu/sslharden/SSL_comp_report2011.pdf
My Server is configured to accept both SSLv3 and TLS1.0 protocols. But a few clients are sending below handshake parameters and after the server hello, the client drops the connection and sends 'handshare failure(40) alert, not sure if it's the client fault or server.
Here's the initial client hello packet:
Secure Socket Layer
SSLv3 Record Layer: Client Hello
Content Type: Handshake (22)
Version: SSL 3.0 (0x0300) <-----------------
Length: 103
Handshake Protocol: Client Hello
Handshake Type: Client Hello (1)
Length: 78
Version: TLS 1.0 (0x0301) <-------------
Random
Session ID Length: 0
Cipher Suites Length: 18
Cipher Suites (9 suites)
The Record layer is SSL 3.0 but the inside handshake protocol is TLS 1.0. My question is, is this the right way of doing it i.e. using different versions for each layer? if it is what method is it? I can't find it anywhere, I looked through the RFC but can't find any reference. Also, how can I produce such requests?
EDIT: I'm not interested in troubleshooting and fixing the issue, I just want to know how can I send such packets? Any command? And what should I name this method?
i.e. I can use curl or openssl to either use ssl3 or tls1 but that would send same version in both record layer and handshake layer:
curl -v -ssl3 https://www.mywebserver.com
Above curl command would look on wireshark:
EDIT2: Is this even legal? I have been googling around and can't find any example. Is it violating any rfc standards?
Thanks
Yes, this is legal (at least it was clarified in recent TLS specifications).
You can look this up in rfc5246 (TLS 1.2) or in rfc6101 (SSL 3.0) or other rfc's concerning the SSL/TLS. The problem is with the initial version of the record protocol and with the handshake protocol:
rfc5246:
Earlier versions of the TLS specification were not fully clear on
what the record layer version number (TLSPlaintext.version) should
contain when sending ClientHello (i.e., before it is known which
version of the protocol will be employed). Thus, TLS servers
compliant with this specification MUST accept any value {03,XX} as
the record layer version number for ClientHello.
TLS clients that wish to negotiate with older servers MAY send any
value {03,XX} as the record layer version number. Typical values
would be {03,00}, the lowest version number supported by the client,
and the value of ClientHello.client_version.
Regarding the handshake protocol, the client will negotiate the highest version that it has implemented:
client_version: The version of the TLS protocol by which the client wishes to
communicate during this session. This SHOULD be the latest
(highest valued) version supported by the client
I just want to know how can I send such packets? Any command?
openssl s_client -connect www.myserver.com:443 -no_ssl2
should produce something similar to the trace you provided.