Skip to main content


CA Certificate chain and traceroute of

Today i come across a funny domain, name; Its funny not because of its name but because of the certificate chain and traceroute to this domain. Both subCA hierarchy and tracroute, has the full lyrics of Bad Horse song. Interesting stuff and amazing use of technology.

Flaw in ServerKeyExchange messages of TLS Protocol

Here we will discuss the flaw in the ServerKeyExchange messages of the TLS protocol which caused the Logjam attack over TLS while using Diffie-Hellman Key Exchange. Before SSLv3, we don't use to authenticate the ServerKeyExchange messages where server negotiates with client regarding usage of cipersuite and parameters. From onwards SSLv3, TLS send the signed message where it mention about parameters it will use but remain silent over ciphersuite. Or in other words, signed portion contains parameters but not contain information about ciphersuite the server will going to use. Now just to remind you, the difference between DH and DH-EXPORT is the size of parameters only. So how to use this flaw - If the server supports DH-EXPORT, an attacker (Men-in-the-Middle) can edit the negotiation sent by the client (even if client doesn't support DH-EXPORT), and replace the list of client supported ciphersuite with DH-EXPORT only. The server will in turn send back a

“FREAK” -- Factoring attack on RSA-EXPORT Keys

FREAK attack allows an attacker to intercept the SSL/TLS traffic between the vulnerable client & server and force them to use week encryption, typically Export Grade encryption (i.e, 512 bit RSA key exchange), which an attacker can break and steal the confidential data. FREAK attack was announced on March 3, 2015 and was discovered by Karthikeyan Bhargavan at INRIA in Paris.  The FREAK attack is possible when a vulnerable browser connects to a susceptible web server—a server that accepts “export-grade” encryption. Vulnerable TLS Clients- OpenSSL - Versions before 1.0.1  Vulnerable Web Browsers- Chrome - Versions before 41 Android Browsers - Vulnerable as they rarely gets updates Acknowledgements -

Export Grade Cryptography

What is export grade cryptography ? Since World War II, many countries including the U.S., U.K. and others, have regulated the export of cryptography in the interest of national security till 1992. Those countries used to believe that they had developed more advanced cryptographic solution than others and they wished to monitor the communication of other countries and hence restricted the advanced cryptographic solution to other nations, by their companies. Restriction had been eased down in 1992 and in 2000 but some are still there. Only those cryptography solutions which can be breaked by security agencies, were allowed to export and were known as Export Grade Cryptography. Ciphers itself are not of Export Grade as they properly follows algorithms. It is the use of cryptographic keys that are deliberately weekend so that security agencies can crack them as and when needed. The export-grade encryption had 512 bits, the maximum allowed under U.S. restrictions de

Server Name Indication (SNI)

TLS does not provide a mechanism for a client to tell a server the name of the server it is contacting. It may be desirable for clients to provide this information to facilitate secure connections to servers that host multiple 'virtual' servers at a single underlying network address. For taking care of this issue, SNI extension has been added into the TLS and published in RFC 6066 . Or to explain it in other words, Name-based virtual hosting allows multiple DNS hostnames to be hosted by a single server (usually a web server) on the same IP address. To achieve this the server uses a hostname presented by the client as part of the protocol (for HTTP the name is presented in the host header). However, when using HTTPS the TLS handshake happens before the server sees any HTTP headers. Therefore, it is not possible for the server to use the information in the HTTP host header to decide which certificate to present. SNI addresses this issue by having the client send the name of

TLS Session Resumption

The extra latency and computational costs of the full TLS handshake impose a serious performance penalty on all applications that require secure communication. To help mitigate some of the costs, TLS provides an ability to resume or share the same negotiated secret key data between multiple connections. Session Identifiers  The first Session Identifiers (RFC 5246) resumption mechanism was introduced in SSL 2.0, which allowed the server to create and send a 32-byte session identifier as part of its "ServerHello" message during the full TLS negotiation which we discuss in TLS Handshake.  Internally, the server could then maintain a cache of session IDs and the negotiated session parameters for each peer. In turn, the client could then also store the session ID information and include the ID in the "ClientHello" message for a subsequent session, which serves as an indication to the server that the client still remembers the negotiated cipher suite and keys fr