It seems that on june 11th, something changed on the Nest servers that prevent my software to run properly on windows XP / windows server 2003.
I don't know what changed exactly but now none of the TLS ciphers supported on win XP are accepted by the Nest servers
I tested all of them using curl:
curl -v --tlsv1 --ciphers EXP-RC4-MD5 https://firebase-apiserver05-tah01-iad01.dapi.production.nest.com:9553/devices.json?auth=<my_token>
* About to connect() to firebase-apiserver05-tah01-iad01.dapi.production.nest.com port 9553 (#0)
* Trying 54.196.73.38... connected
* successfully set certificate verify locations:
* CAfile: none
CApath: /etc/ssl/certs
* SSLv3, TLS handshake, Client hello (1):
* Unknown SSL protocol error in connection to firebase-apiserver05-tah01-iad01.dapi.production.nest.com:9553
* Closing connection #0
curl: (35) Unknown SSL protocol error in connection to firebase-apiserver05-tah01-iad01.dapi.production.nest.com:9553
If someone from Nest is reading this, would it be possible to enable at least one of the cipher supported by win XP?
alternatively is there a way to have more ciphers supported by SChannel in win XP? For example AES128-SHA works with the Nest servers using curl
Windows XP support ended in April last year (2014) and Windows Server 2003 support ends in a few days (14 July 2015). As a result they are limited to support older, and less secure protocols/ciphers.
I think you are out of luck with this one. If you had to I guess you could proxy the requests from legacy clients via another API that does support the less secure combinations of protocols/ciphers and then forward those requests to Nest. I wouldn't recommend it however.
Just make sure you consider any possible security ramifications.
If you're using a specific .net library for fire base I know one of other person to run into issues. So maybe check your fire base library or try a new one.
Related
I recently migrated a Home Assistant (HASSIO) instance from Ubuntu 18.04 to Ubuntu 20.04. While setting up MQTT, I noticed that TLS security option for MQTT was set as "tlsv1" and MQTT broker was reporting this as an error while starting the service:
Error: Unsupported tls_version "tlsv1"
I had to change this to a supported TLS version and tlsv1.3 did the trick. In /etc/mosquitto/conf.d/default.conf:
tls_version tlsv1.3
MQTT broker is now up and working. However Owntracks client from Android Phone has trouble connecting to the MQTT Broker. It constantly shows SSL Handshake error.
Any idea what could be wrong? Do I need to update the certificates on Owntracks to support the new TLS version?
After some head banging, it seems tls version 1.2 works fine without changing the CA certificates on the Android device. I tried all options - tlsv1.1, tlsv1.2 and tlsv1.3 and only tlsv1.2 seemed to work for now.
It also seems that TLS v1.3 is the most secure option and given a chance it should be used if possible. The only problem is that CA certificates are distributed across a number of my Android devices and this is more of a logistcs issue. However for the time being, below option in /etc/mosquitto/conf.d/default.conf works fine:
tls_version tlsv1.2
Hope this helps others facing similar problems.
I am getting this warning on mobile devices, the full warning is:
The connection uses TLS 1.2
The connection is encrypted using AES_256_CBC, with HMAC-SHA1 for message authentication and ECDHE_RSA as the key exchange.
I am using a dedicated VPS for the website and I have used IISCrypto with best practices applied.
You can see the results of the site scanner with the link below.
Qualys Scan Results
The Schannels I am using are below:
Schannel configuration
Chipher Suit Configuration
The Server is Windows 2012 r2 with IIS
Any help would be very grateful.
Paul.
To cite from the Chromium documentation what you need to do to make this warning go away:
... prioritize an ECDHE cipher suite with AES_128_GCM or CHACHA20_POLY1305. Most servers will wish to negotiate TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
Looking at what Windows Server 2012 R2 actually supports on ciphers you'll find that it does not support CHACHA20_POLY1305 and that it supports GCM ciphers only with ECC certificates, i.e. it implements ciphers like TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256_P256 but not ciphers like TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256.
But, you are using an RSA certificate and not an ECC certificate which means that none of the GCM ciphers supported by your OS can be used with your certificate. The ciphers you need are only supported with Windows Server 2016.
I have 100 HTTPS services running on a single server using SNI. (Actually, I don't have access to them. It's an assignment. All I know are their domain names N.xxx.yy where N is in range from 00 to 99.) The goal of the assignment is to evaluate security of every single connection to each of these servers. So some of the servers contain expired certificates, certificates with wrong CN, etc.
My problem is that I cannot get past the handshake on some of the servers. I have written my own application in C++ using OpenSSL, but I've also tried it with openssl s_client. This is how I connect to the server:
openssl s_client -host N.xxx.yy -port 443 -verify 1 -servername N.xxx.yy -CAfile assignment-ca.pem
And this is what I get:
139625941858168:error:14094438:SSL routines:ssl3_read_bytes:tlsv1 alert internal error:s3_pkt.c:1493:SSL alert number 80
139625941858168:error:140790E5:SSL routines:ssl23_write:ssl handshake failure:s23_lib.c:177:
In Wireshark, I see that client sent ClientHello, server responded with ServerHello (choosing TLSv1.2 and ECDHE-RSA-AES256-GCM-SHA384) followed by Certificate and then it sent me Alert message containing Internal Error (80).
After trying different thing I have found out that if I run s_client with -tls1 or -tls1_1 I can successfully get past the handshake. -tls1_2 does not work. What is even stranger is that connection through Chrome/Firefox/any other browser succeeds even if TLSv1.2 is negotiated. From what I see, Chrome is sending a different cipher list than me or s_client but even after modifying the cipher list to match the one in Chrome (and making sure that server chooses ECDHE-RSA-AES128-GCM-SHA256), it does not work either. Chrome is sending these TLS extensions, which I don't but most of them seem empty:
Unknown 47802
renegotiation_info
Extended Master Secret
signed_certificate_timestamp
status_request
Application Layer Protocol Negotiation
channel_id
Unknown 6682
Can anybody explain me what is happening here? Unfortunately, I have no way to debug it on the server side so this is all I know.
UPDATE:
After playing around with forged ClientHello messages I managed to track it down to signature_algorithms extension. My app and s_client provide SHA384 + {RSA,DSA,ECDSA} but if I remove these and keep just SHA256 + {RSA,DSA,ECDSA}, as Chrome does, it works and I receive Server Key Exchange message successfully. Could it be that server somehow does not support it, but instead of providing meaningful error message, it just ends unexpectedly and gives me this internal error?
UPDATE 2:
I found answer to why it works with TLS versions prior to 1.2 in RFC5246. Question from the previous UPDATE still holds.
Note: this extension is not meaningful for TLS versions prior to 1.2.
Clients MUST NOT offer it if they are offering prior versions.
However, even if clients do offer it, the rules specified in [TLSEXT]
require servers to ignore extensions they do not understand.
Since you wrote that -tls1_2 does not work I assume either you and/or the server uses an older openssl library. The current version while writing this is 1.1.0e
There were quite some fixes since 0.9.8, which could often be seen on older systems.
For Version 1.0.1 there was this fix, which sounds like your problem:
`Some servers which support TLS 1.0 can choke if we initially indicate
support for TLS 1.2 and later renegotiate using TLS 1.0 in the RSA
encrypted premaster secret. As a workaround use the maximum permitted
client version in client hello, this should keep such servers happy
and still work with previous versions of OpenSSL.`
Maybe also notable:
Don't allow TLS 1.2 SHA-256 ciphersuites in TLS 1.0, 1.1 connections.
So I would suggest to update your openssl-Version and in case of the servers out of your control I would stick to the settings you already found.
I use a Tcl script to pull from several API's and all of a sudden some API's stopped working. eg:
set data [http_call_get https://api.vineapp.com/timelines/popular?page=1&anchor=1]
responds with the error:
SSL Channel "sock624": error: sslv3 alert handshake failure
It's odd that two of the five API's from different sites stopped working within an hour or each other so I feel that something changed with the compatibility of the tls1.6.3.1 tcl package which binding with "::http::register https 443 ::tls::socket"
I've tried on three different machines (2 x Windows and a ubuntu box).
The sites you are attempting to connect to have probably disabled sslv3 due to the poodle vulnerability.
I would guess your tcl script needs to use TLS instead.
Following a really outdated tutorial I managed to create an HTTPS server using OpenSSL with TLS1.2, and I'm very proud of it ;)
However TLS 1.2 is only supported in latest browsers and I would like to have some kind of negotiation of the protocol between the client and server, which I'm sure it can be done, but I'm not able to find how! So that if the client only supports TLS1.0, well use that. And if it only supports SSLv3, use that. Not sure about SSLv2, maybe better leave that...
The code I use right now is:
SSL_library_init();
OpenSSL_add_all_algorithms();
SSL_load_error_strings();
ssl_method = TLSv1_2_server_method();
ssl_ctx = SSL_CTX_new(ssl_method);
Then the server certificates are loaded and the ssl_ctx is shared among all connections. When a client is accepted by the server socket it is encapsulated in an SSL object (whatever it represents):
ssl = SSL_new(ssl_ctx);
SSL_set_fd(ssl, client_socket);
SSL_accept(ssl);
So I guess that something has to be changed in the ssl_ctx creation to allow more methods... Any idea?
<rant> No decent, extensive documentation can be found for OpenSSL, the best available is a 10 years old tutorial! </rant>
Thanks in advance.
You do this by using SSLv23_method() (and friends) instead of a specific method (e.g. TLSv1_2_server_method() in your example). This sends the SSLv2 ClientHello but also specifies the highest protocol supported. The somewhat outdated man page says:
SSLv23_method(void), SSLv23_server_method(void), SSLv23_client_method(void)
A TLS/SSL connection established with these methods will understand
the SSLv2, SSLv3, and TLSv1 protocol. A client will send out SSLv2
client hello messages and will indicate that it also understands SSLv3
and TLSv1. A server will understand SSLv2, SSLv3, and TLSv1 client
hello messages. This is the best choice when compatibility is a
concern.
This online man page doesn't discuss the newer TLSv1_1 and TLSv1_2 protocols, but I verified in the 1.0.1g source of s23_clnt.c that SSLv23_method() includes them.
You then limit the protocols you actually accept with SSL_CTX_set_options():
The list of protocols available can later be limited using the
SSL_OP_NO_SSLv2, SSL_OP_NO_SSLv3, SSL_OP_NO_TLSv1 options of the
SSL_CTX_set_options() or SSL_set_options() functions. Using these
options it is possible to choose e.g. SSLv23_server_method() and be
able to negotiate with all possible clients, but to only allow newer
protocols like SSLv3 or TLSv1.
Note, however, that you can't enable arbitrary sets of protocols, only contiguous protocols in SSLv2, SSLv3, TLSv1, TLSv1_1, TLSv1_2. For example, you can't choose only SSLv3 and TLSv1_1, omitting TLSv1. This comment in the source explains why:
SSL_OP_NO_X disables all protocols above X if there are some protocols below X enabled. This is required in order to maintain "version capability" vector contiguous. So that if application wants to disable TLS1.0 in favour of TLS1>=1, it would be insufficient to pass SSL_NO_TLSv1, the answer is SSL_OP_NO_TLSv1|SSL_OP_NO_SSLv3|SSL_OP_NO_SSLv2.