TLS version intolerance, also referred to as protocol intolerance, is a pervasive bug in web server software. When present, it can prevent an SSL\/TLS connection from being established.<\/p>\n
The SSL\/TLS protocol has had five major revisions<\/a> over its 20+ year life. Despite all the improvements and lessons that have been learned through those iterations, the underlying problem causing version intolerance was not fixed until recently<\/a>. The next version, TLS 1.3, will resolve the majority of version intolerance problems. However, software that poorly conforms to the SSL\/TLS specification will continue to have this bug, which will still present a significant hurdle for the industry.<\/p>\n TLS version intolerance is a problem that occurs during the SSL Handshake, the process through which an SSL\/TLS connection is made.<\/p>\n To start a handshake, the client \u201cadvertises\u201d its TLS capabilities in a message known as ClientHello<\/em>. This involves the client telling the server all its technical capabilities, including the newest protocol version it supports. For instance, a modern client like Google Chrome would say \u2018I support TLS 1.2.\u2019<\/p>\n The server would then compare those capabilities to its own, choose the strongest methods available, and send its choices back so that both parties know how they will be making the connection \u2013 this message is the ServerHello<\/em>. If the server did not support the same protocol version, it would send back the next newest version it does support. For example, it\u2019s common that servers are further behind the curve than clients, so the server may say \u2018I support TLS 1.1. If you do too, let\u2019s use that.\u2019<\/p>\n Having agreed upon TLS 1.1, the rest of the handshake occurs and a connection is made. That\u2019s how everything should <\/em>work.<\/p>\n When there is TLS version intolerance, things don\u2019t go quite so smoothly. In our above example, the problem would occur when the server receives the ClientHello<\/em>. If the server does not recognize the advertised TLS version, it simply stops the connection there. This is not what the SSL\/TLS specification calls for, but a large amount of software implements it improperly and small mistakes are abundant.<\/p>\n Usually, servers experience version intolerance when a new protocol is released. For example, the software code may only be written to understand what versions existed at the time. So when a new version is presented, it has no instructions on how to react.<\/p>\n The answer is TLS 1.3. Now, it\u2019s not that there is anything specifically wrong with TLS 1.3. Version intolerance is an issue anytime a new protocol version is released. TLS 1.3 just happens to be the next version of the TLS protocol, due to be completed soon<\/em> (internet standards work takes a long time. It is hard to say exactly when TLS 1.3 will be finalized \u2013 but it\u2019s something that the internet has begun preparing for).<\/p>\n New TLS protocol versions are a big deal \u2013 the current version, TLS 1.2 \u2013 was released back in 2008. Needless to say, there have since been major advances in protocol design, cryptography, and security, which will be incorporated into 1.3.<\/p>\n But new data<\/a> published by Qualys suggests that deployment of TLS 1.3 may be problematic because of servers with version intolerance. Their SSL Pulse project scans the SSL\/TLS configuration of 150,000 of the world\u2019s most popular websites each month.<\/p>\n SSL Pulse found that, as of last month (July 2016), 3.2% of servers have problems properly responding to SSL handshakes which offer TLS 1.3. Ivan Risti\u0107, who works on the SSL Pulse project, said \u201c[3.2%] doesn\u2019t sound like much, but it\u2019s a huge problem for browsers because it translates to thousands of sites, some very popular.\u201d<\/p>\n Fixing version intolerance problems either requires that servers fix their software through an update, or the problem can be fixed on the client side. Web browsers implement a mechanism known as voluntary protocol downgrade<\/em>. It is essentially an intelligent auto-retry, where the browser continues to initiate new handshakes, incrementally advertising lower protocol versions until the connection is successful. Without this mechanism, trying a new connection would just lead to the same failure over and over \u2013 because each time the client would advertise the problematic version.<\/p>\n Unfortunately, voluntary protocol downgrade<\/em> has downsides. Negotiating a connection takes longer when it is used, because the browser is actually making multiple attempts one after another. These downgrades also pose a security risk. \u00a0Version intolerance is a problem that really needs to be fixed on the server-side, instead of having browsers compensate for it.<\/p>\n Ivan Risti\u0107 is the author of Bulletproof SSL and TLS<\/a>, and is one of the world\u2019s leading experts on SSL\/TLS. He hared his thoughts on protocol design and version intolerance on the Qualys blog<\/a>.<\/p>\n Future versions of SSL Pulse will continue to publically track version intolerance.[1]<\/a><\/p>\n [1]<\/a> https:\/\/twitter.com\/BhushanLokhande\/status\/761007853503180800<\/a><\/p>\n","protected":false},"excerpt":{"rendered":" New Data From SSL Pulse Shows\u00a0TLS Version Intolerance Continues to Cause Issues TLS version intolerance, also referred to as protocol intolerance, is a pervasive bug in web server software. When…<\/p>\n","protected":false},"author":2,"featured_media":2972,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"inline_featured_image":false,"footnotes":"","tve_updated_post":"","tve_custom_css":"","tve_user_custom_css":"","tve_globals":{},"tcb2_ready":0,"tcb_editor_enabled":0,"tve_landing_page":"","_tve_header":"","_tve_footer":""},"categories":[130],"tags":[136,161,165],"class_list":["post-2861","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-everything-encryption","tag-ssl","tag-tls","tag-tls-version-intolerance","post-with-tags"],"views":13205,"jetpack_featured_media_url":"https:\/\/www.thesslstore.com\/blog\/wp-content\/uploads\/2016\/08\/iStock_59915522_MEDIUM.jpg","_links":{"self":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts\/2861","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/comments?post=2861"}],"version-history":[{"count":0,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/posts\/2861\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/media\/2972"}],"wp:attachment":[{"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/media?parent=2861"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/categories?post=2861"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.thesslstore.com\/blog\/wp-json\/wp\/v2\/tags?post=2861"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}What is Version Intolerance?<\/h2>\n
Why is TLS Version Intolerance a problem now?<\/h2>\n