Skip to main content


Showing posts from 2015

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

TLS Handshake

Before the client and the server can begin exchanging application data over TLS, the encrypted tunnel must be negotiated: the client and the server must agree on the version of the TLS protocol, choose the cipher suite, and verify certificates if necessary. Unfortunately, each of these steps requires new packet roundtrips between the client and the server, which adds startup latency to all TLS connections. 0 ms TLS runs over a reliable transport (TCP), which means that we must first complete the TCP three-way handshake, which takes one full roundtrip. 56 ms With the TCP connection in place, the client sends a number of specifications in plain text, such as the version of the TLS protocol it is running, the list of supported ciphersuites, and other TLS options it may want to use. 84 ms The server picks the TLS protocol version for further communication, decides on a ciphersuite from the list provided by the client, attaches its certificate, and sends the respon

HTTP/1.0 and HTTP/1.1

HTTP is a protocol used to exchange or transfer hypertext.  Hypertext is structured text that uses logical links (hyperlinks) between nodes containing text. Tim Berners-Lee and his team at CERN are credited with inventing the original HTTP along with HTML and the associated technology for a web server and a text-based web browser. Berners-Lee first proposed the "WorldWideWeb" project in 1989 — now known as the World Wide Web. The first version of the protocol had only one method, namely GET, which would request a page from a server. The response from the server was always an HTML page.                                                         Tim Berners-Lee authored/co-authored multiple RFCs (Request for Comment) including  RFC 1945  (which was published in 1996 and talks about Hyper Text Transfer 1.0), RFC 2068  (which describes HTTP/1.1 & was published in 1997), RFC 2616  (which obsoletes the RFC 2068 and made HTTP/1.1 official). Because of his extensive work towards

SPDY (pronounced speedy); NPN (Next Protocol Negotiation); ALPN (Application Layer Protocol Negotiation) and HTTP/2

SPDY (pronounced as SPeeDY) :- SPDY is an experimental protocol developed at Google, designed to reduce the latency of web pages. Specifically, its goal is to address the limitations of HTTP/1.1 and to remove existing bottlenecks like:-  - head of line blocking,  - inefficient use of underlying TCP connections,  - and header bloat SPDY achieves reduced latency through compression, multiplexing, and prioritisation. The name "SPDY" is a trademark of Google and is not an acronym. Implementing a new protocol across the web, where varieties of devices exists along with multiple range of OS across platforms, is like play with fire. This may lead to random dropped connections with no or very little troubleshooting information and will cause frustration for the end user. To deal with this, SPDY is delivered via SSL. End-to-end encrypted tunnel allows the client and the server to exchange SPDY frames without intervention by intermediate nodes. It's important

Cipher Suites

A cipher suite is a named combination of authentication , encryption , message authentication code (MAC) and key exchange algorithms used to negotiate the security settings for a network connection using the Transport Layer Security (TLS) / Secure Sockets Layer (SSL) network protocol. Usage When a TLS connection is established, a handshaking, known as the TLS Handshake Protocol, occurs. Within this handshake, a client hello (ClientHello) and a server hello (ServerHello) message are passed. First, the client sends a cipher suite list, a list of the cipher suites that it supports, in order of preference. Then the server replies with the cipher suite that it has selected from the client cipher suite list. Description of Algorithms In cryptography, a  message authentication code (MAC)  is a short piece of information used to authenticate a message and to provide integrity and authenticity assurances on the message. A MAC algorithm, accepts as input a secret key and an arbi