Tag Archives: TLS

TLS 1.0 and 1.1 Upcoming End of Support Announced

Early last week saw a coordinated effort from almost major browser vendor to follow the guidelines of the PCI-DSS standard and to end support for TLS 1.0 and 1.1

Why should this change be considered relevant?
Each of the browser vendors have worked together to create a definite timeline (starting in 2020 and complete by July 2020) for the end of support of these now obsolete security protocols. TLS 1.0 is almost 20 years old and is no longer PCI-DSS compliant.  Separately TLS 1.1 is more than 10 years old. They both contain known vulnerabilities e.g. BEAST (an attack), DROWN or FREAK (both downgrade attacks) etc. use insecure hash functions (e.g. MD5 and SHA-1) and receive very little use today:

0.4% from Apple Safari (<0.36% for all connections) (Source: WebKit)

0.5% for Google Chrome (Source: Google)

1.2% of Firefox Beta 62 during the time August-September 2018 (Source: Mozilla)

0.72% for Microsoft Edge (Source: Microsoft)

More modern standard e.g. TLS 1.2 offers improved performance when used with HTTP/2 and are PCI-DSS compliant. Moreover, it doesn’t suffer from all of the vulnerabilities affecting prior versions and includes stronger alternatives to older hash functions e.g. ECDHE_RSA_WITH_AES_128_GCM_SHA256 .

What does the future hold?
Following the recent deprecation of any standard of TLS older than 1.2 on the 30th of June this year due to the mandate set by the PCI Security Standard Council has steadily seen the increase of the recently ratified TLS 1.3 (in April 2018) but defined within (Request for Comments) RFC 8446 in August. This is in part due to a change by Mozilla to Firefox in April and the adoption of the newest standard by some popular websites e.g.:

Google’s Gmail (although the newer standard isn’t always enabled)

https://www.bleepingcomputer.com/

https://www.securityweek.com/

https://nakedsecurity.sophos.com

https://www.theregister.co.uk/

https://www.wordpress.com (which also includes this blog you are reading!)

The OpenSSL Foundation added full TLS 1.3 support to their popular cryptographic library OpenSSL with the release of version 1.1.1 in September 2018. OpenSSL are further driving adoption of the newest standard by ending support for the current long term support (LTS) version 1.0.2 by the end of 2019 (with it only receiving security updates after the 31st December 2018).

The increase in traffic is best illustrated by Mozilla showing approaching 6% usage for Firefox Beta 62 during the time August-September 2018. Such an increase is really good news for the security of the Internet specifically any online service that requests personal information and e-commerce websites in particular.

For more information on which web browsers support TLS 1.3, please see this link with a table from Salesforce illustrating browser support for TLS 1.2 here.

Thank you.

Blog Post Shout Out: SHA-1 Migration and Internet of Things (IoT)

With the transition to SHA-2 rapidly approaching (January 2017) if you have not already begun the migration process for your website or are having difficulties locating all of the certificates that need migrating; the following article that I wish to provide a respectful shout out to may be of assistance. The article includes advice on making the best use of the remaining time:

SHA-1 Time Bomb: One Third of Websites Have Yet to Upgrade by Phill Muncaster (Infosecurity Magazine)

This issue is also of note since Google (like the other browser vendors is moving away from SHA-1) will remove support for SHA-1 in Chrome version 56. Further details are provided in their blog post. The source of the statistics for the Infosecurity Magazine article was this blog post from Venafi, an organisation that provides cryptography related solutions and services to enterprises.

=======================
With the DDoS attack (defined) against the DNS service Dyn last month attributed to Internet of Things (defined) devices further steps need to be taken to secure them. To assist with this, the US CERT have written a PDF document titled “Strategic Principles for Securing the IoT”. It is intended for consumers, operators and manufacturers of IoT devices. It is available from the link below:

Securing the Internet of Things (US-CERT)

=======================
Thank you.

OpenSSL 1.1.0 Adds Partial TLS 1.3 Support

====================
Update: 1st April 2018:
====================
With the approval of TLS 1.3 by the IETF after 28 drafts (at the time of writing their February 2018 blog post OpenSSL had implemented draft 23) of the now completed standard.

This approval brings the upcoming implementation of TLS 1.3 one step closer. As noted in the news article I linked to above; it will take time before we begin to see websites migrating to it and may be some years before it becomes an everyday protocol.

As highlighted in that article, the transition won’t be straightforward but, in my opinion, will be more than worth our efforts.

Thank you.

====================
Update: 14th February 2018:
With the publication of the first alpha of OpenSSL 1.1.1; OpenSSL is moving closer to a release version with full TLS 1.3 support.

Thank you.
====================
Update: 17th November 2016:
Since publishing this blog post, the OpenSSL Foundation have provided more information on their timetable for implementing TLS 1.3. They intend to have full TLS 1.3 support in the next feature release of OpenSSL 1.1, namely 1.1.1. Further details are available within OpenSSL’s blog post.

Moreover, in late October Mozilla announced that the upcoming version of Firefox 52 set for release in March 2017 will come with TLS 1.3 enabled by default. Firefox 49 was the first version to have this feature built-in but it needed to be enabled within the about:config page of the browser’s settings by setting security.tls.version.max version to value of 4 Firefox 52 will have this setting enabled by default.

Thank you.

====================
Original Post:
====================
On the 25th of August the OpenSSL Software Foundation released OpenSSL 1.1.0 which brought partial support for a working IETF draft of TLS 1.3. OpenSSL 1.1 is one of the largest version changes to have occurred in the history of OpenSSL which is now better funded, has more developers and follows an improved code development process following the discovery of the now well-known Heartbleed vulnerability.

What is TLS 1.3?
Transport Layer Security (TLS) version 1.3 is the most recent version (currently in draft form) of the cryptographic protocol originally based on SSL (Secure Socket Layer) version 2 (from 1995) and v3 from 1996. This is the protocol that protects us when we see the HTTPS displayed in our web browsers address bar. More information on TLS/SSL is available in this podcast, this page and this blog post.

Why Is TLS 1.3 an advancement over TLS 1.2 or 1.1?
TLS 1.3 removes support for known insecure ciphers such as RC4, DES, 3DES and export grade ciphers as well older hashing algorithms e.g. SHA-1 and MD5. These are welcome changes that should help to reduce the possibility of further vulnerabilities such as SWEET32 and FREAK being present within the code of TLS libraries e.g. OpenSSL.

This reduces the attack surface (defined within the second paragraph of this blog post) of TLS 1.3 but the improvements don’t stop there. Cipher suites such as NIST P-256 and AES-GCM are being removed as primitives with only x25519, ChaCha20 and Poly1305 remaining developed by Dan Bernstein (who uses the handle djb).

X25519 is a key exchange protocol (with a similar purpose to Diffie Hellman), ChaCha20 is a stream cipher (a more secure alternative to the older RC4) and Poly1305 is used as a message authentication code (defined) with a view to replacing GCM.

In addition to improved security TLS 1.3 will offer improved performance but protection against reply attacks was still being finalised in the closing months of 2015.

Conclusion
With the many implementation vulnerabilities that have been uncovered in recent years within SSL and TLS the upcoming TLS 1.3 standard is a significant step in the right direction. With web browsers such as Mozilla Firefox, Google Chrome, Microsoft Edge (in progress) and other implementations adding support for TLS 1.3, the new standard is off to a promising start.

Thank you.

NTP Project Releases Security Update

In late October the NTP Project; the maintainers of the Network Time Protocol (NTP)(defined) issued a security update to resolve 13 medium and low CVEs (defined) in this commonly used protocol. This update brings the version of NTP to 4.2.8p4.

Why Should These Issues Be Considered Important?
3 of the issues addressed by this security update were discovered and responsibly disclosed (defined) to NTP by 4 researchers from Boston University. Their research is described in this paper.

The first issue involves the use of a Kiss-of-Death packet that is normally used to prevent a client device (e.g. a desktop or laptop computer etc.) from repeatedly requesting the correct time from an NTP server when the client device may be experiencing technical issues. This prevents the NTP server becoming inadvertently overloaded. An attacker can exploit this issue by sending a Kiss-Of-Death packet to a victim device from any location (what is known as an off-path attack). This packet depending on the poll value within it has the potential to prevent that victim device from correctly setting it’s clock for a year or more.

The second issue resolved is very similar but involves the attacker sending a large number of queries requesting the correct time to the NTP server. These queries have been spoofed to look like they came from the victim device. The server then responds to the victim device with the above mentioned Kiss-Of-Death packet again disabling the victim devices means of updating it’s clock. This issue could be exploited if the first issue mentioned above has already been patched on the time server. This results in the victim device experiencing a denial of service issue (defined) since it can no longer set it’s clock due to no fault of it’s own.

The third and final issue requires that the attacker be positioned in a man-in-the-middle (defined) position between the client and the server which could allow the attacker to roll back the time on the victim device that bypasses the 16-minute threshold that is usually imposed to prevent a server from setting a client devices clock more than 16 minutes from the actual correct time.

If a device has its clock set to an inaccurate time that differs too much from the correct time it can cause that device to no longer be able to carry out actions that primarily use correct time to function properly. The use of timestamps is primarily employed in cryptography to prevent replay attacks (defined) or to determine if a digital certificate is still valid (among other purposes). For the full details of how features such as TLS (defined here and here), DNSSEC (defined), DNS (defined) (among others) as well as the online cryptocurrency Bitcoin can be affected as a result of these issues please refer to page 2 and 3 of the above mentioned paper.

Since the above features (among others) rely on a device having an accurately set clock and given that an attacker can exploit these 3 issues relatively easily these issues should be patched as soon as possible.

How Can I Protect Myself from These Issues?
NTP is available for most operating systems primarily Linux and Mac OS X (however versions for Windows also exist). In addition, almost any device can request the correct time from an NTP server and thus could be affected by these issues even if NTP is not installed on the device (but would need to be installed on the server).

Full details of these issues are provided by the NTP project on this page (see the October 2015 entry). Updated versions of NTP are available from this page. For Linux systems the relevant updates can also be obtained via the Package Manager bundled with your Linux distribution (see this link (Debian) and this link (Ubuntu) that should assist you in using the package manager for your distribution of Linux). Apple usually update NTP via their App Store and Software Update, details are available on this page.

In addition, recommendations to more thoroughly protect against all of the flaws discussed in the above mentioned research paper are provided on this page.

Thank you.

Why Your Organizations Website Should Migrate From SHA-1

Update: 15th March 2017:
The first practical attack against SHA-1 took place in February 2017 and is discussed in a more recent blog post.

Thank you.

=======================
Update: 25th June 2016:
Microsoft have updated their SHA-1 deprecation roadmap to state that from the 12th of July changes described in that psot will be seen for Microsoft Edge, Microsoft Internet and Windows 10 (with the Anniversary update) with regard to how they display the status of SHA-1 certificates. Further details are available within that post.

Thank you.
=======================

Update: 10th January 2016:
As mentioned in a recent blog post Mozilla have needed to re-enable SHA-1 certificates for “man-in-the-middle” (defined) devices due to issues being experienced by companies/organizations using such devices.

In addition, in mid-December Google announced their schedule for phasing out SHA-1. They too are considering moving the deadline forward to 1st July 2016 but have set a hard deadline of the 1st January 2017.

At the end of their blog post announcing this schedule they also provide advice on migrating from SHA-1. It is notable that within Step 2 of their plan they mention they took into account the issue Mozilla encountered (mentioned above; however, Google published that blog post before Mozilla Firefox users encountered that issue and worked around it in advance).

The migration from SHA-1 poses some very difficult issues for both users who cannot upgrade their web browsers before the imposed deadlines as well as corporate users who will be unable to make the transition in time (e.g. they are using custom applications that are critical to their business). These issues are discussed here with a possible work around being voted upon by the CA/Browser Forum discussed in a separate post.

Thank you.
=======================

Update: 24th November 2015:
Since publishing this blog post last month Mozilla and Microsoft are considering moving forward the deadline for phasing out SHA-1 to the 1st of July 2016. Their decisions have come in light of the recent disclosure of potential attacks on SHA-1 previously discussed within this blog post. The final deadline has not yet been decided but this should be yet another reason to begin planning to move your organization’s website away from using SHA-1.

Thank you.

=======================
Original Post:
=======================
Earlier this month a report was published by a team of researchers which shows that a potential attack on a SHA-1 hash (defined) could take as little as 3 months and cost in the region of USD $75k to $125k. The time and cost necessary are significantly less than the previous 2012 estimates of $700k necessary in 2015 and $173k by 2018.

Why Should This Potential Attack Be Considered Important?
In October 2012 possible attacks on SHA-1 were discussed and estimates provided on how time such attacks would take to carry out. Migration away from SHA-1 at the time was suggested. With the publication of the new research this month the need for migration has become more important.

An attack against the MD5 hash algorithm in 2012 was used by malware known as Flame to allow the installation of the malware onto PCs by making it “look like” genuine Windows Updates from Microsoft.

This was accomplished by the malware authors making improper use of Microsoft’s Terminal Services licensing certificate authority (CA)(defined). The certificate used to sign the updates was created using the MD5 algorithm (defined). A hash collision attack (defined) was used by the malware authors to make a different signing certificate produce the same hash as that of the genuine signing certificate. This seemingly “genuine” certificate was then used to sign their malware making it look like those malware files were Windows Updates.

While weaknesses in the MD5 algorithm were used to accomplish this, the same method of attack could potentially be used with SHA-1 to once again make malware look like legitimate/non-malicious files. When I say this, I don’t mean that an attack of this kind could again be carried out against Windows Update but I am referring to the use of SHA-1 in general. It’s not uncommon to see SHA-1 hashes provided when downloading new software or software updates from a software vendor’s website. If those files could be replaced with malware that has an identical hash to that of the legitimate file, the same type of attack could be carried out. You could download the file which would be malware but it would have the same SHA-1 hash as the genuine software.

SHA-1 is not only used for code-signing certificates but also with TLS (defined) secured websites. For example, if a website e.g. example.com has a legitimate certificate, that certificate could potentially be used by an attacker to provide more trust to a website of their choice using a collision attack on SHA-1. Thus when you visit the attackers website, malware.com it would appear to have a legitimate/trusted certificate. If this fake certificate were used in combination with another attack e.g. pharming (defined)(also discussed further in this post), there is the potential for you to visit example.com and actually be taken to the attacker’s website but example.com would appear in your web browsers address bar (while at the same time having a seemingly legitimate TLS certificate making the website appear even more trustworthy).

How Can I Protect Against The Known Weaknesses in SHA-1?
If you would like to check if your website uses a SHA-1 certificate you can visit this website. That site also provides advice on obtaining a newer SHA-2 certificate.

In addition this link provides advice on generating a new TLS SHA-2 certificate. Moreover a list of compatible web browsers, operating systems, web servers, databases, firewalls etc. is provided here. Finally the current planned roll-out phases of SHA-2 is provided here. Moreover you may find that this article provides useful background information and advice. For TLS certificates, the deadline for transition to SHA-2 is currently January 2017.

However a ballot with the CA/Browser Forum wishes to extend the issuing of SHA-1 certificates throughout 2016 giving large organizations with too many certificates to switch over during 2016 more time to do so. It appears from this post that this 1 year extension was granted (please see the update below for clarification on this).

Update: 4th January 2016:
I have been contacted in relation to the CA/Browser forum vote and have been informed that Symantec withdrew their ballot and the Baseline Requirements section on SHA-1 are unchanged. Many thanks to Mr. E. Mill for this information.

Update: 7th February 2016:
Qualys in September 2014 published a thorough blog post detailing how to migrate from SHA-1 including what to do should you need to support devices that cannot migrate from SHA-1.

I hope that the above information is useful to any organization or individual wishing to migrate their websites TLS certificate from SHA-1 to SHA-2.

Thank you.