Only some (not all) users are receiving ERR_SSL_PROTOCOL_ERROR in Chrome when attempting to visit my express site. I am not receiving this error, so it is proving a pain to debug.
I am creating a https server using a PFX file I downloaded from my provider (1&1):
var options = {
pfx: fs.readFileSync('./mysite_private_key.pfx'),
passphrase: 'MYPASSPHRASE',
};
https.createServer(options, app).listen(443);
https://whatsmychaincert.com tells me that the chain is correct but complains about the handshake:
[mysite] has the correct chain.
[mysite]: TLS handshake error:
error:14077438:SSL routines:SSL23_GET_SERVER_HELLO:tlsv1 alert
internal error SSL Labs might be able to tell you what went wrong
I've googled this with no success, does anyone know what the problem could be? Ty.
In the end I ditched 1&1 and used GoDaddy's CA service and the problem went away.
A possible source of failed handshake could be the lack of an intermediate certificate, ca option of tls.createSecureContext. It should by public on your provider's website.
Hope this helps.
nowadays , when our server (e.g. 1&1) is securely configured , only tls v1.2 and tls v1.3 are supported ..
so how you debug this:
scan your site with SSL Labs Test too see which ciphers are supported , or alternately see in our nginx/apache config
tail -f the server logs , especially the catchall/other_vhosts log files,since ssl protocol errors might be in the site logs and the generic catchall log when the server cannot decide on the name
try to update the users chrome to support at least tls 1.2
chrome has the some command line switches to change its cipher behaviour:
--ssl-version-max Specifies the maximum SSL/TLS version ("tls1.2" or "tls1.3"). ↪
--ssl-version-min Specifies the minimum SSL/TLS version ("tls1", "tls1.1", "tls1.2", or "tls1.3"). ↪
DANGER ZONE:
as last resort you could try to accept legacy ciphers in your nginx-config ( ssl_ciphers directive) like socat OR (very last resort) socat23 to check which version your clients support,
remember to disable everything below tls v1.2 in production environment
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.
For over a year I have been running a photo based website that allows customers to order prints, which are subsequently fulfilled by a printing company. Orders are posted in XML format to a designated URL. Recently it has come to my attention that the orders are not being post and I have found the following error when examining the server logs:
[Mon Dec 01 21:17:38 2014] [error] [client XXX] cURL error: [35] Cannot communicate securely with peer: no common encryption algorithm(s).
The tech team for the printing company was able to provide me with some direction, but I remain confused. Initially they informed me that the server currently supports SSLv2, SSLv3 and TLS 1.0 only, and that it was likely that we only have TLS 1.2 enabled on our end. They claimed that nothing was changed on their end, and I personally know that nothing has been modified on ours for months.
When I originally encountered the problem I attempted to update the server packages, but this failed to resolve the problem. Later I thought that perhaps the issue revolved around the security groups for the Amazon EC2 instance, but I am not entirely sure. How would I go about enabling TLS 1.0, assuming it is not already enabled? How would I check what transport layer securities and secure socket layers are currently enabled? Any other suggestions?
If you can route the traffic through an HTTP proxy, you can install Fiddler and see what is in the TLS negotiation info:
By default on most systems libcurl already speaks TLS 1.0 fine if that's what the server wants.
I rather suspect your problem is that the server insists on using a cipher for this URL that libcurl won't agree to. More specifically, I would suspect it is an RC4-using cipher and RC4 is deemed insecure and is disabled by default by libcurl.
Any way to detect if a remote website supports SPDY and what version it is?
Something I can use from the command line like a bash script.
Tried sending custom User-Agent headers with curl but can't get any kind of response headers that would help me.
The idea is to be able to get SPDY:true/false Version:3.1/3.0... for any domain.
openssl s_client -connect google.com:443 -nextprotoneg ''
CONNECTED(00000003)
Protocols advertised by server: spdy/3.1, spdy/3, http/1.1
The SPDY protocol negotiation happens during the initial TLS handshake.
There are currently two ways to negotiate the protocol: the older one is called NPN (https://datatracker.ietf.org/doc/html/draft-agl-tls-nextprotoneg-04).
In the ClientHello TLS message the client sends the NPN extension with ID 0x3374. The server replies with a ServerHello TLS message that also contains the list of protocols supported by the server also in a NPN extension.
The client then chooses the protocol and sends its choice, encrypted, to the server.
The newer method has been designed for HTTP 2.0 and is called ALPN (https://datatracker.ietf.org/doc/html/draft-ietf-tls-applayerprotoneg-05).
The ClientHello TLS message contains the ALPN extension with ID 0x10.
The client, this time, sends the list of protocols supported and the server replies with a ServerHello TLS message that contains the protocol chosen by the server, also in a ALPN extension.
In both the NPN and ALPN extension the list of protocols is sent as strings such as http/1.1 or spdy/3.
Once the protocol has been chosen, the TLS handshake continues and then both parties will start to speak immediately the protocol that they have chosen.
The only way to be aware of negotiation of the protocol is therefore to use TLS and to have a client that exposes the protocol negotiation extensions.
Each client does that in a specific way, but there is not yet support for bash scripts, as far as I know.
HAProxy for example has support for both NPN and ALPN (http://cbonte.github.io/haproxy-dconv/configuration-1.5.html) and Jetty 9.2 too has support for both NPN and ALPN (both for clients and servers).
Other servers like Nginx or Apache have support for NPN with patches for ALPN (since it will be needed by HTTP 2.0 anyway).
NPN will eventually fade away; Google's Adam Langley has stated that NPN will be deprecated in favour of ALPN.
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.