When using ssl_version of TLSv1_2 and the receiver is using tls version 1.0, will it honor both tls version 1 and 1.2?
conn.use_ssl = useSSL
conn.ssl_version="TLSv1_2"
conn.verify_mode = OpenSSL::SSL::VERIFY_NONE
By setting conn.ssl_version="TLSv1_2", you are forcing the TLS version to exactly TLS 1.2. thus, the connection will be negotiated either with this exact version, or not at all. If the server only offers TLS 1.0, TLS 1.1 or even (exclusively) TLS 1.3, then the connection will not be established.
Note that this is unrelated to the verify_mode which only affects how the certificates presented by the server are validated. With OpenSSL::SSL::VERIFY_NONE, you are telling the client that it should not check whether the certificates can be validated against any trusted root certificates. The server must still provide a syntactically valid certificate and "correct" encryption.
Related
I have created a spring-boot backend java application with a React front end, and I am trying to use the GCP.
I got it working on AppEngine and wanted to put a long-running version of the application on a VM in Compute Engine, but when I deploy it on the vm in compute engine and try to connect to the app with HTTPS it gives me "ssl3_get_record:wrong version number". This is even when I am trying to connect to the app inside of the vm itself with 'localhost'.
It is a pretty cut and dry spring boot application that uses the embedded tomcat server. It contains a WebSecurityConfigureAdaptor and a WebMvcConfigurer for CORS mapping.
Has anyone run into this issue or can give me some guidance on what I need to do to fix it?
EDIT:
Adding curl -i -v https://localhost as requested
* Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 3001 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (OUT), TLS alert, unknown CA (560):
* SSL certificate problem: self signed certificate
* Closing connection 0
curl: (60) SSL certificate problem: self signed certificate
More details here: https://curl.haxx.se/docs/sslcerts.html
curl failed to verify the legitimacy of the server and therefore could not
establish a secure connection to it. To learn more about this situation and
how to fix it, please visit the web page mentioned above.
ssl3_get_record:wrong version number means the client can't open a connection to the server because they likely don't support the same TLS versions or settings.
SSLv3 was decommissioned quite a while ago. Either it's old an old java version or they never updated the function name. What java versions are you using?
Logs indicates the app may be running on HTTP/2 (ALPN, offering h2) and with TLSv1.3. These are definitely not supported well in old clients in my experience, like what a java enterprise typically uses. Consider disabling HTTP/2 or TLS1.3 and try again.
The widely used and supported SSL version is TLS 1.2 nowadays. See this other question on forcing TLS versions in a java app. Since OpenJDk Java 11 getting javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure
The app may be running on a self-signed certificate. You can get a public certificate from let's encrypt.
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.
I am relating to Application and invalid certificate errors
When i initiate the call with Twilio REST API, and then pick up the phone, i can hear that error occured and Certificate Invalid - Could not find path to certificate appears in my alert dashboard.
However, certificate is located in the mozila certificate program, i can find certificate at Public All Intermediate Certs List. I dont use self signed certificate.
As soon as i disable SSL Certificate Validation inside Twilio Console Account settings, the problem is gone.
My result from qualys ssl lab are:
Summary:
This server is vulnerable to the POODLE attack. If possible, disable SSL 3 to mitigate. Grade capped to C.
This server accepts RC4 cipher, but only with older protocols. Grade capped to B.
The server does not support Forward Secrecy with the reference browsers.
This server's certificate chain is incomplete. Grade capped to B.
Configuration:
SSL 3 INSECURE
Cipher Suites:
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) WEAK
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) DH 4096 bits FS WEAK
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH secp256r1 (eq. 3072 bits RSA) FS WEAK
TLS_RSA_WITH_RC4_128_SHA (0x5) INSECURE
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) ECDH secp256r1 (eq. 3072 bits RSA) FS INSECURE
Protocol details:
Secure Renegotiation Supported
POODLE (SSLv3) Vulnerable INSECURE SSL 3: 0xa
Downgrade attack prevention Yes, TLS_FALLBACK_SCSV supported
RC4 Yes INSECURE
Forward Secrecy With some browsers
Shall i disable SSL or do you have any ideas what can i do?
Twilio developer evangelist here.
I am hoping that your https://ssllabs.com/ssltest has scared you sufficiently enough. You need to upgrade your server from SSLv3 to TLS as SSLv3 and a lot more of your setup is insecure and will not protect you in the face of an attack.
Twilio has deprecated support for SSLv3 and supports TLS. This is likely why you are getting an invalid certificate error.
For the sake of your and your users own security and safety, please upgrade your server.
Is it possible to use TLSv.1.2 or TLSv1.1 with Ruby?
I have compiled a Frankenstein version of Ruby using OpenSSL 1.0.1c (the latest available) and the only difference being is SSLv2 is now an option under OpenSSL::SSL::SSLContext::METHODS
Is it possible to add TLSv1.2 to that list?
Yes, we added TLS 1.1 & 1.2 support recently. It's as easy as setting ssl_version on your SSLContext:
ctx = OpenSSL::SSL::SSLContext.new
ctx.ssl_version = :TLSv1_2
You may still continue to use the more generic :SSLv23 for maximum interoperability. It will have the effect that the newest protocol supported by the peer will be used for the connection. If your peer understands TLS 1.2, then it will be used. But opposed to the above sample, if the peer does not speak 1.2, then the implementation will silently fall back to the best/newest version that the peer does understand - while in the above example, the connection would be rejected by the peer if it did not recognize 1.2.
For further details, also have a look at OpenSSL's own docs on the subject, you can transfer what's being said about TLSv1_method to TLSv1_1_method and TLSv1_2_method (represented in Ruby as :TLSv1, :TLSv1_1 and :TLSv1_2 respectively).
If your underlying OpenSSL supports TLS 1.2 (>= 1.0.1 does), you're good to go. However, this requires a Ruby build from trunk currently. But if we get no negative feedback in the meantime, it might well be that it will be backported to the next 1.9.3 release.
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.