According to wikipedia: http://en.wikipedia.org/wiki/Transport_Layer_Security
Seems like TLS is a replacement to SSL, but most websites are still using SSL?
In short, TLSv1.0 is more or less SSLv3.1. You can find more details in this question on ServerFault.
Most websites actually support both SSLv3 and TLSv1.0 at least, as this study indicates (Lee, Malkin, and Nahum's paper: Cryptographic Strength of SSL/TLS Servers: Current and Recent Practices, IMC 2007) (link obtained from the IETF TLS list). More than 98% support TLSv1+.
I think the reason why SSLv3 is still in use was for legacy support (although most browsers support TLSv1 and some TLSv1.1 or even TLSv1.2 nowadays). Until not so long ago, some distributions still had SSLv2 (considered insecure) on by default along with the others.
(You may also find this question interesting, although it's about the usage pattern of TLS rather than SSL vs. TLS (you could in fact have the same pattern with SSL). This does not apply to HTTPS anyway, since HTTPS uses SSL/TLS from the beginning of the connection.)
From http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authenticity/
In the early 90’s, at the dawn of the World Wide Web, some engineers at Netscape developed a protocol for making secure HTTP requests, and what they came up with was called SSL. Given the relatively scarce body of knowledge concerning secure protocols at the time, as well the intense pressure everyone at Netscape was working under, their efforts can only be seen as incredibly heroic. It’s amazing that SSL has endured for as long as it has, in contrast to a number of other protocols from the same vintage. We’ve definitely learned a lot since then, though, but the thing about protocols and APIs is that there’s very little going back.
There were two major updates to the SSL protocol, SSL 2 (1995) and SSL 3 (1996). These were carefully done to be backwards compatible, to ease adoption. However backwards compatibility is a constraint for a security protocol for which it can mean backwards vulnerable.
Thus it was decided to break backwards compatiblity, and the new protocol named TLS 1.0 (1999). (In hindsight, it might have been clearer to name it TLS 4)
The differences between this protocol and SSL 3.0 are not dramatic, but they are significant enough that TLS 1.0 and SSL 3.0 do not interoperate.
TLS has been revised twice, TLS 1.1 (2006) and TLS 1.2 (2008).
As of 2015, all SSL versions are broken and insecure (the POODLE attack) and browsers are removing support. TLS 1.0 is ubiquitous, but only 60% of sites support TLS 1.1 and 1.2, a sorry state of affairs.
If you're interested in this stuff, I recommend Moxie Marlinspike's clever and funny talk at
https://www.youtube.com/watch?v=Z7Wl2FW2TcA
tls1.0 means sslv3.1
tls1.1 means sslv3.2
tls1.2 means sslv3.3
the rfc just changed the name, you could find tls1.0's hex code is 0x0301, which means sslv3.1
TLS maintains backward compatibility with SSL and therefore the communication protocol is nearly identical in any of the mentioned versions herein. The two important differences between SSL v.3, TLS 1.0, and TLS 1.2, is the pseudo-random function (PRF) and the HMAC hashing function (SHA, MD5, handshake), which is used to construct a block of symmetric keys for Application Data encryption (server keys + client keys + IV). Major difference between TLS 1.1 and TLS 1.2 is that 1.2 requires use-of "explicit" IV to protect against CBC attacks, although there is no changes to PRF or protocol needed for this. TLS 1.2 PRF is cipher-suite-specific, which means PRF can be negotiated during handshake. SSL was originally developed by Netscape Communications (historic) and later maintained by Internet Engineering Task Force (IETF, current). TLS is maintained by the Network Working Group. Here are difference between PRF HMAC functions in TLS:
TLS 1.0 and 1.1
PRF(secret, label, seed) = P_MD5(S1, label + seed) XOR P_SHA-1(S2, label + seed);
TLS 1.2
PRF(secret, label, seed) = P_hash(secret, label + seed)
"If it ain't broken, don't touch it". SSL3 works fine in most scenarios (there was a fundamental flaw found in SSL/TLS protocol back in October, but this is a flaw of applications more than of a procol itself), so developers don't hurry to upgrade their SSL modules. TLS brings a number of useful extensions and security algorithms, but they are handy addition and not a must. So TLS on most servers remains an option. If both server and client support it, it will be used.
Update: in '2016 SSL 3, and even TLS up to 1.2 are found to be vulnerable to various attacks and migration to TLS 1.2 is recommended. There exist attacks on implementations of TLS 1.2 as well, though they are server-dependent. TLS 1.3 is currently in development. And now TLS 1.2 is a must.
https://hpbn.co/transport-layer-security-tls/ is a good introduction
The SSL protocol was originally developed at Netscape to enable ecommerce transaction security on the Web, which required encryption to protect customers’ personal data, as well as authentication and integrity guarantees to ensure a safe transaction. To achieve this, the SSL protocol was implemented at the application layer, directly on top of TCP (Figure 4-1), enabling protocols above it (HTTP, email, instant messaging, and many others) to operate unchanged while providing communication security when communicating across the network.
When SSL is used correctly, a third-party observer can only infer the connection endpoints, type of encryption, as well as the frequency and an approximate amount of data sent, but cannot read or modify any of the actual data.
SSL 2.0 was the first publicly released version of the protocol, but it was quickly replaced by SSL 3.0 due to a number of discovered security flaws. Because the SSL protocol was proprietary to Netscape, the IETF formed an effort to standardize the protocol, resulting in RFC 2246, which was published in January 1999 and became known as TLS 1.0. Since then, the IETF has continued iterating on the protocol to address security flaws, as well as to extend its capabilities: TLS 1.1 (RFC 2246) was published in April 2006, TLS 1.2 (RFC 5246) in August 2008, and work is now underway to define TLS 1.3.
Feature
SSL
TLS
Full Name
Secure Socket layer
Transport layer security
Created By
Netscape in 1994
In 1994, IETF took over the maintenance of SSL and later renamed it
Note: The world used the mostly TLS over SSL.
Related
I am currently implementing OpenSSL's TLS/SSL standards into my mail service, allowing my users to select the TLS/SSL version they want. Here is the list of versions:
["TLSv1","TLSv1_server","TLSv1_client","SSLv3","SSLv3_server","SSLv3_client","SSLv23","SSLv23_server","SSLv23_client","TLS","TLSv1_1_server","TLSv1_1_client","TLSv1_1","TLSv1_2","TLSv1_2_server","TLSv1_2_client"]
I did some Googling on what the difference of the options are, and I understand that some versions are deprecated, or shouldn't be used because of security issues, such as TLSv1. I don't understand the difference between the client vs server ones, but from my own testing, the server options return errors when trying to send a mail with it.
So my question is - of that list, what should I remove?
What you show are not SSL/TLS versions but various types of SSL contexts which also include the usable SSL/TLS versions. This means the *_server "versions" are all SSL contexts which should be used on the server side where you usually also need a certificate. The *_client variants are for the client side of the TLS handshake, i.e. the one which initiates the TLS handshake.
Within a mail client you don't want to use any server specific SSL contexts because with these the mail client would expect the peer to start with the TLS handshake which it does not.
For more details see the man page of SSL_CTX_new which has a detailed description of what all these different contexts mean.
... allowing my users to select the TLS/SSL version they want.
While your specific implementation is wrong the idea of letting users chose the protocol version is wrong too. Instead you should just use a generic context without limitations (apart from disabling insecure versions) so that it automatically picks the best protocol version during the TLS exchange. Selecting specific protocol versions should only be done in case the peers TLS stack is broken, like for stacks which simply refuse a TLS 1.2 handshake instead of replying with TLS 1.0 in case they don't support TLS 1.2.
I'm working on snmpv3. In the RFC and internet I haven't seen any documentation regarding how the encryption and hashing algorithms exchanged between the entities. I wonder will there be any cipher negotiation happens in SNMPv3 or both parties should agree upon a specific set of algorithms prior to the communication and use them?
I wonder whether you are reading the proper RFC documents. For SNMP v3 there is no cipher negotiation at all. You have to know exactly how a device is configured so as to manage it.
It is not something like HTTP over SSL.
I am currently seeing a vulneribility post scanning for Downgrade Prevention Attack on my website, I did a quick check on google and figured out TLS Fallback Signaling Cipher Suite Value (SCSV) can be used for Preventing Protocol Downgrade Attacks,
But can anyone suggest what changes will i have to make to my IBM HTTP server conf files to prevent this vulneribilty. If not how can we implement TLS Fallback Signaling Cipher Suite Value (SCSV)
djrecker.
IHS doesn't support SCSV, which is a protocol that enables browsers to do slightly less unsafe non-TLS negotiation when they see connections abruptly closed.
You could disable SSLv3 so there is no "weak" protocol to allow this to downgrade to.
In SSL connections. As far as I understand that the the order of the cipher suit that the client offers to the server matters. How can I know what is the order of the client's offered cipher suit in my Firefox or IE browsers?
In FF, I tried to type about:config and then filtered the output to: security.ssl, I got:
Is this is the exact order that the client offers to SSL servers? Does this means, my browser prefers DHE and ECDHE over RSA key exchange because the DHE and ECDHE ciphers came first?
There is nothing in the TLS RFC that says the order matters. Specific servers may choose to honor the order provided by the client as an order of preference, but it isn't required, and neither JSSE not OpenSSL does so to the best of my knowledge.
How can I identify the cipher strength of an active https connection to a linux redhat apache webserver. I want to harden my web server by removing lower strength ciphers and would like to check if clients are even using them.
EDIT
My goal is to avoid negative impact of removal of a lower security cipher that a client relies on. Worst case scenario there is a stupid non browser (or old browser) app that is using an old insecure cipher, when I disallow the use of this cipher his/her app could break. I'm trying to proactively identify if there are any apps/browsers using any of the ciphers I'm going to disable.
You can identify unsuccessful handshakes by enabling the appropriate level of logging on mod_ssl. See the Custom Log Formats section on http://httpd.apache.org/docs/2.2/mod/mod_ssl.html, notably
CustomLog logs/ssl_request_log \ "%t %h %{SSL_PROTOCOL}x %{SSL_CIPHER}x \"%r\" %b"
This should enable you to make a list of ciphers requested by clients and configure Apache accordingly.
Your question and your goal aren't necessarily related. Each active connection may use a difference cipher based on the combination of: (a) the capabilities on the server (b) the capabilities of the client (c) cipher preference of the server and client. Looking at any individual connection will not tell you if your SSL configuration is optimal.
If your goal is to harden your SSL configuration, I suggest you use
the SSL Server Test from SSL labs. It grades your server configuration based on known SSL vulnerabilities and best practices.
The last time I updated my SSL configuration I used the configuration tips from this blog post. Note that understanding of SSL vulnerabilities is constantly changing so I suggest you rerun the test every once in a while to ensure your configuration is the best that is currently known.