Essay on Transport Layer Protocol 1.2 Technology

Transport layer protocol (TLP) is the latest version of secure socket layer (SSL) that has been defined by the Internet Engineering Task Force (IETF). It is used to negotiate a secure connection to the mail or web server and encrypts the data on the move. The protocol is based on the secure socket layer version SSL 3.0. Its major goal is to make the protocols specification more precise and complete and to make the secure socket layer more secure. TLS 1.2 added new, stronger encryption options but retained most of the old, weaker encryption schemes that had undergone backward compatibility. A person who can perform a man-in-the-middle attack could downgrade the connection to a weaker encryption system without the users awareness. The attacks are the reason for the upgrade to TLS 1.3. TLS provides the enhancements over SSL Version 3.0 by ensuring a more secure MAC algorithm, granular alerts, and a clearer gray area specification definition. The security improvement provided by Transport layer protocol are Key-Hashing for message authentication, the enhancement of pseudorandom function (PRF), an improved finished message verification, consistent handling of the certificates, and specific message alerts CITATION Sta13 \l 1033 (Stallings, 2013).

Support for TLS 1.3

The current version of transport layer security is TLS 1.2 whereas TLS 1.3 is available as a draft. TLS 1.3 is based on TLS 1.2 but provides the security and privacy improvement over the protocols supported by the web browser. TLS 1.3removes the support for a cryptographic hash function such as the prohibited use of insecure SSL or RC negotiation, elliptic curves, digital exchange algorithm, stream ciphers, and the key exchange protocols. It is faster as compared to TLS 1.2 since it has reduced the number of trips to 1.

Early 2017, Akamai announced TLS 1.3. It was funded by the OpenSSL Software Foundation to accelerate their plans to support TLS 1.3 in the OpenSSL cryptographic library. The library is among the leading libraries used by the servers and the clients to secure SSL/TLS connections on the internet. The majority of the vulnerability that affected TLS 1.2 could not affect TLS 1.3 because of the changes in the protocol. TLS 1.3 designers abandoned the legacy encryption systems that caused security problems. It provides the protocols significant overhaul securing HTTPS communication, improving the performance and the close architectural vulnerabilities. The connection will still fall back to TLS 1.2 if the other terminal is not TLS 1.3 compatible. If MITM attacker attempts to force the fallback, it will be detected under TLS 1.3. Most of the websites support TLS 1.2; some are still running the earlier and less secure protocol. The paying processors urge that the sites that are using their services to upgrade to the secure versions of TLS before June 30, 2018. June 30, 2018, is the deadline that has been imposed by the payment card industry security standards council.

The beta program has been launched for TLS 1.3 for customers with custom certificates. The clients can enable it during the beta period if the customer certificates secure the web properties. Controls exist in the Certificate Provisioning System (CPS) allowing one to configure to configure their customer certificates from the TLS 1.3 beta. The certificates are configured with two specific settings CITATION Pat17 \l 1033 (Patil, 2017). The settings are the existing certificate provisioning system interface present in the portal and the new beta interface of CPS.

The new TLS version is still undergoing IETF standardization process, and hence different crypto browsers, libraries, and web servers have implemented different non-interoperable draft versions. The final version will be ratified as an RFC, which the clients will connect with TLS 1.3. After the approval of TLS 1.3 specification by IETF, TLS 1.3 will be made available for all the web properties on the Akamai Secure CDN. It will be available as a platform feature for the customers and deliver products. The client will continue using Akamai Defaults and select an-Akamai-default-2017q3 cipher profile after which the Akamai default list of TLS protocol versions will include TLS 1.3. TLS 1.3 will be enabled with the Akamai shared certificate in 2018. The support for additional features such as 0-RTT early data and origin connections may be supported.

The Cloudflare trends

It is quite complex to upgrade a security protocol in an ecosystem. One needs to update the clients and servers and ensure that everything continues to work correctly. Currently, the internet is in the middle of such an upgrade. The transport layer security, a protocol which is keeping the web browsing confidential is getting the major overhaul with the introduction of TLS 1.3. Cloudflare is the first provider to support TLS 1.3 on its server. There is no major browser which has enabled TLS 1.3 by default.

The middleboxes are the reason as to why the TLS 1.3 has not yet been deployed. Middlebox is a network appliance designed to monitor and intercept HTTPS traffic inside a corporate environment and the mobile network CITATION Hil17 \l 1033 (Hill, 2017). Some middleboxes implemented TLS 1.2 incorrectly and that what blocks the browsers from releasing TLS 1.3. Blaming network appliances is disingenuous, the reality is that TLS 1.3 as it was originally designed was incompatible with how the internet has been evolving.

Cloudflare has tried to enable beta features such as allowing customers with a more complex network to choose in when they are ready and automate for non-paying customers CITATION Aum17 \l 1033 (Aumasson, 2017). The major glitches Cloudflare were from the client side but not on the server side. Some organizations that use the security appliances to monitor the web-browsing habits of their users found out that the connections to the servers running TLS 1.3 were dropped without any warning and hence blocking the access to the site. The successive implementation of TLS 1.3 will not please the governments who want to contact surveillance or banks to comply with the regulations preventing collusions among the traders. They will not have the solution to access the traffic and monitor it.

Depreciation of SHA-1 Certificates

SHA-1 Signed Certificates is an encryption hash that is used as a digital fingerprint using then SHA-1 algorithm. For an algorithm to be a cryptographic hash rather than a plain old checksum, it needs to create an algorithm that is genuinely hard to forge. For instance, taking message M, a digital figure print can be created by calculating f (m) = X. One should be able to go backward and figure out a message of their own, e.g., message Y such that f (Y) is also X. One should not come up with two different messages that have used the same fingerprint, where f (M) = f (Y) bit M is not equal to Y. If the conditions are not met, the hashing function is not safe to use as a digital fingerprint in cryptography. If one can deliberately create a collision, for instance, by coming up with a second message that has the same fingerprint as the original message, even if the altered message is garbage, the original message can be refuted by showing the fallibility of the signature being relied on.

Recent research in cryptography has shown that SHA-1 Signed Certificates has numerous vulnerabilities. Even though no one has ever created a forged SSL certificate by constricting SHA-1 collisions, experts consider the risk quite high that it should consider inevitable. The SHA in SHA-1 can no longer be considered as security has an algorithm CITATION Ber15 \l 1033 (Berretti, 2015). The stronger variants of the SHA-1 algorithm including SHA-256 are easy to use, and they have existed for years, and hence there is no reason to continue using SHA-1 SSL certificates when they can be easily replaced with more secure technology. There are timelines from Microsoft, Mozilla, Apple, and Google as to when their browsers will stop supporting the websites that are still using SHA-1 SSL certificate.

Call for the use SHA-1 to be dropped started way back in 2005. NIST updated its guidelines in 2012 recommending the deprecation of SHA-1 as the standard CITATION Sim16 \l 1033 (Simpson, 2016). In 2013, Microsoft announced an aggressive policy to remove SSL / TLS certificates that had been signed using the SHA-1 hashing algorithm. In 2014, Google developed a plan to start penalizing the sites that were still using SHA-1 in SSL certificate after 2016. The websites that are still using SHA-1 SSL certificate have a high profile warnings to make the switch. The warnings include the Heartbleed vulnerability that forced many websites using SSL to deploy to new certificates and hence an opportunity to use a stronger fingerprint algorithm at the same time.

Certificate viewers certificate error in High Sierra and Safari

Apple has introduced a new version of an operating system, high Sierra for watchOS 4, macOS, tv OS 11, and IOS 11. It has taken some time to elaborate on the improvements made to the SSL/TLS support and the cryptographic library of the platform. The certificate error UI has been redesigned in Safari and a high Sierra certificate viewer.

In safari, the error age has been modeled such that it gives a plan-English explanation of the problems without the need to invoke jargons like signatures and protocols. The certificate viewer has a more specific messaging. Apple published a new revocation checking method for their platform. The method initializes by scanning the certificate transparent logs. The scanning of certificate transparent logs enables it to discover the certificates that are trusted on their platform. The method then queries the revocation status of the discovered certificates from the certificate authority. The information concerning the revoked certificate is packaged together and then automatically distributed to the clients device at the regular intervals.

On connection to the TLS protocol, clients validate to found out if the certificates are marked as revoked form the centralized list. If they are marked as revoked, clients perform live Online Certificate Status Protocol checks to confirm the accuracy. Once the confirmation has been received, clients understand the certificates have been revoked, and it has refused to make a connection. If servers provide stapled Online Certificate Status Protocol responses, they will use it for confirmation instead of performing live checks. If the certificates are not marked as revoked by the centralized list, Online Certificate Status Protocol will not be used.

In high sierra, Apple switched to LibreSSL from OpenSSL. LibreSSL library is a fork of OpenSSL that is supported by OpenBSD. The secure transport is Apples API for SSL/TLS. Secure transport is primarily used for their first party software. It serves as the SSL library for third-party software. The new Apple OSes supports ATS exemptions in various frameworks such as WebView, Webkit, and AVFoundation. The Exemptions will be configurable for local network connections. Exceptions will be scoped to a particular domain name and the entire application if the need arises. The client will be able to specify if they are interested in having the hostnames certificate checked for the certificate transparency compliance.

High Sierra and iOS 11 supports draft specifications for TLS 1.3, which are assumed to be similar to the final product of TLS 1.3. It has enabled the developers to commence the testing of TLS 1.3 ahead of its final release. The platform of Apple is catching up with the industries standards of deprecating the aging cryptography and hashing algorithm. High Sierra, iOS 11, wat...