When browsing the internet about TLS and SSL I found that on 30th June 2018, IETF are prohibiting SSL and TLS 1.0 because of exploits such as POODLE (Found it on this website: https://blog.pcisecuritystandards.org/are-you-ready-for-30-june-2018-sayin-goodbye-to-ssl-early-tls). IsIETF or another organisation/company making an alternative to SSL so all protocols that use it (not just HTTPS) will still work?
When browsing the internet about TLS and SSL I found that on 30th June 2018, IETF are prohibiting SSL and TLS 1.0 ....
While you don't provide a source for this claim ("browsing the internet" is not a useable source) I think you are confusing several things here:
SSL 2.0 is broken for years, SSL 3.0 is considered broken too (POODLE attack), TLS 1.0 has known weaknesses but is not considered critically broken (POODLE does not apply here, except for buggy implementations which did not correctly implement the standard)
The IETF is not prohibiting TLS 1.0 on 30th June 2018. Instead this date comes from the PCI security standards councel which is relevant for example for payment providers.
The document Migrating from SSL and Early TLS includes the following statement:
After June 30, 2018, all entities must have stopped use of SSL/early TLS as a security control, and use only secure versions of
the protocol (an allowance for certain POS POI terminals is described in the last bullet, below)
Here "early TLS" refers to TLS 1.0 and "SSL" to SSL 3.0 which means that one can still use TLS 1.1 and TLS 1.2 and also the new TLS 1.3 wherever PCI requirements apply. And you can continue to use TLS 1.0 outside these requirements (i.e. for non-payment sites) although use of the well supported and more secure TLS 1.2 (or better) is recommended. Also, all modern OS and browsers have support for TLS 1.2 for years, thus there is no need to worry.
Related
They are a few posts on the web talking about and around it but not explaining the differences and significances. A Client Hello packet can be seen to have a Record Layer and Handshake Protocol version - 0x0301 and 0x0303. What is the difference between them? Which TLS version is being used when one of them shows 1.0 and the other indicates 1.2?
The TLS record layer version is 1.0 because the TLS version is negotiated on the basis of version mentioned in client hello. For example, if the client asks to use 1.2 and send the client hello to server and server asks to use 1.3 strictly then TLS record would never know which version will be negotiated.
As such, it use 1.0 as generic.
The RFC tells you the same:
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."
I want to capture a sample SSL traffic with wireshark, which it's version is TLS1.3(newest version). I enabled the TLS 1.3(draft23) flag in chrome browser, and also update my wireshark to version 2.6.2.
then I start to open some sites like https://gmail.com and https://www.thesslstore.com which supports this version and capture the traffic.
but when I open the captured traffic, the version of SSL header is TLS1.0 or TLS1.3 while in the section of the protocol in the top of window, TLSv1.3 is showed.
There are routers, gateways, etc. that look at this header. Because TLS 1.3 is somewhat new, you will often see older TLS versions specified. I most often see TLS 1.2, but my code talks to AWS - that may be their standard.
I'm a novice in regards to Transport Layer Security stuff, to bear with me...
I have some https web apps that I test locally using self-signed certs created with selfssl.exe. The company recently pushed new rules to everyone's machines that prevent the browsers from loading https sites that use anything other than TLS 1.2. However, my browsers give me certificate errors when I load my locally-hosted test stuff if TLS 1.0 is not enabled. Is it possible to generate self-signed certs that will work with my browsers if only TLS 1.2 is enabled?
I'm using Windows 7 64 bit with IIS 7.5, and I test with a variety of browsers (IE 11, Firefox 46, and Chrome 50).
No, it is not possible
SSL/TLS in all versions works with x509 digital certificates. The difference between TLS versions is the protocol rules, not the certificate.
The browser warns usually when the used protocol is old(consideres less secure) or the certificate is not trusted
Eventually figured this out. The answer is kinda dumb...
On Windows 7 / Windows Server 2008 R2, the TLS 1.2 protocol is installed, but disabled by default. When Big Brother pushed everybody to TLS 1.2, they did it with SCHANNEL registry entries, but they did not create the "DisabledByDefault" entry set to "0" so it blew up the security of all the Windows 7 users on the domain.
So, if you're going to use registry hacks to push users over to TLS 1.2, be sure to follow the instructions from Microsoft and remember to create a "DisabledByDefault" entry in the TLS 1.2 SCHANNEL key. :-)
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/dn786418(v=ws.11)
We have clients who can be using anything, WindowsXP,Vista,Linux....
Currently our systems support SSLV2 and SSLV3.But, we are planning to disable both SSLV2 and SSLV3 in windows server 2008R2 in favour of TLS 1.2.
Will it have any breaking changes with the end user?I'm worried that If I disable SSLV3 ( and SSLV2) , some of the clients who use windowsXP(for example) might not be able to access my web service.
PS: Tried to find a similar question in stackoverflow, didn't find any. So, posting this as a question. :)
This is one of the scenarios where you will NOT be able to support old clients using insecure protocols and expect to have decent security.
If you have not enabled TLS 1.2 yet, do so.
Some clients do not support TLS 1.2 (e.g., older Android versions). You may need to support TLS 1.0 and 1.1 in addition to 1.2. While not ideal, it is definitely better than supporting SSL 2.0 and 3.0.
Post an announcement indicating that your web service is being upgraded to meet minimum security requirements and set a date for retiring insecure protocols.
Optionally, check your server metrics to see what protocols/ ciphers are used. Since you haven't mentioned your web server, I'm assuming it is IIS, in which case this is not easy[1][2].
Retire SSL 2.0 and SSL 3.0. There will be a few clients who will not be able to connect. Plan to have an answer ready for them. If you have clients running XP and using IE6, they have bigger issues than not being able to access your web service.
While you are at it, run your TLS configuration through an online
scanner like SSL Labs to ensure you fix any other issues.
I would like to display a message to customers who's browser's highest level of encryption is SSLv3. Is it possible for me to target browser settings of SSLv3 and lower? Client or Server code? We will be allowing lower versions of SSL to use our site during a certain grace period. During this grace period, we would like to display a message only to those users that have browser settings of SSL3 or lower.
Not easily. The browser's supported SSL versions are not detectable until the SSL handshake is in progress, and even then only if the browser uses an SSLv2 handshake to allow dynamic version negotiation. If an unsupported version were detected, you would not be able to send a message back since the handshake failed and the connection would be closed before you could send any message. However, SSL itself has an error packet that gets sent during handshaking, and it can specify a version mismatch error.
The best you can do in your own code is support all SSL versions on the server side, let the client complete a handshake normally, and then detect which version was actually used and send back a message if the SSL version is too low.
Or, you could simply enable TLSv1 or higher only, and simply refuse to let older clients connect at all. They just would not get a nice error message unless the browser decided to detect the SSL version mismatch error and display its own pretty message about it.
Firstly, nowadays, you can generally forget about clients that don't support at least SSLv3. SSLv3 has been widely available for many years.
The TLS Client Hello message, sent when the connection is initiated by the browser, should contain the highest TLS version it supports:
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. For this
version of the specification, the version will be 3.3 (see
Appendix E for details about backward compatibility).
Appendix E is of course worth looking at.
(The Client Hello message will also contain the list of cipher suites the client supports, which is possibly relevant for the general idea of your question.)
Of course, this specification is just a "SHOULD", so a client supporting TLS 1.2 could still send a Client Hello for TLS 1.1, but what would be the point? By doing so it would have no chance ever to use TLS 1.2 anyway. It could be a preference box that is turned off, but that would effectively make it a client that doesn't support the highest version anyway. (If you want anything more subtle, you'd need to build a database of known user agents, which will be partly unreliable, and for which you'd need to analyse the full user agent string to know everything possible about the platform.)
Now, how to convey the content of the Client Hello message to your application is another matter, and depends very much on which SSL/TLS stack you use. It might not even be directly possible without modifying that SSL/TLS library or the server you're using.
This being said, you can generally get the negotiated TLS version during the current session quite easily. Since that version is the "lower of that suggested by the client in the client hello and the highest supported by the server" (i.e. "min(max(client), max(server))"). If your server supports SSLv3, TLS 1.0, TLS 1.1 and TLS 1.2, and since the latest version is TLS 1.2 anyway, what you'll get during your current connection will also be the max currently supported by the client. As long as your server supports the latest version, you should be able to know what the client supports at best from any live connection.
If you're behind Apache HTTP server's mod_ssl, you should be able to get that from the SSL_PROTOCOL environment variable. You should also be able to get the protocol from the SSLSession in Java.
(If you are willing to write a more bespoke service, you could pass further details like the cipher suites more directly to your application, like this service from Qualys SSL Labs does, although I'm not sure if it's meant to be widely available or just a test service.)
I'd have to agree with Remy about it being a bit challenging.
However, a good starting point may be to retrieve some SSL (certificate) information.
Something similar to this:
X509Certificate certChain[] =
(X509Certificate[]) req.getAttribute("javax.net.ssl.peer_certificates");
Another way of getting more information is to retrieve the cipher_suite attribute (similar to the code snippet above).
javax.net.ssl.cipher_suite
I hope this (at least) gets you closer.
Good luck.