Comparative Analysis of Open-SSL Vulnerabilities & Heartbleed Exploit Detection (original) (raw)
Related papers
vttls-vulnerability-tolerant.pdf
We present VTTLS, a vulnerability-tolerant communication protocol. There are often concerns about the strength of some of the encryption mechanisms used in SSL/TLS channels, with some regarded as insecure at some point in time. VTTLS is our solution to mitigate the problem of secure communication channels being vulnerable to attacks due to unexpected vulnerabilities in encryption mechanisms. It is based on diversity and redundancy of cryptographic mechanisms and certificates to provide a secure communication channel even when one or more mechanisms are vulnerable. VTTLS relies on a combination of k cipher suites. Even if k−1 cipher suites are insecure or vulnerable, VTTLS relies on the remaining cipher suites to maintain the channel secure. We evaluated the performance of VTTLS by comparing it to an OpenSSL channel.
VULNERABILITIES OF THE SSL/TLS PROTOCOL
This paper analyzes vulnerabilities of the SSL/TLS Handshake protocol, which is responsible for authentication of the parties in the communication and negotiation of security parameters that will be used to protect confidentiality and integrity of the data. It will be analyzed the attacks against the implementation of Handshake protocol, as well as the attacks against the other elements necessary to SSL/TLS protocol to discover security flaws that were exploited, modes of attack, the potential consequences, but also studying methods of defense. All versions of the protocol are going to be the subject of the research but emphasis will be placed on the critical attack that the most endanger the safety of data. The goal of the research is to point out the danger of existence of at least vulnerability in the SSL/TLS protocol, which can be exploited and endanger the safety of the data that should be protected.
A Review and Analysis on Heartbleed on Italian Websites, a Year Later
Heartbleed, a big Open Secure Socket Layer (OpenSSL) vulnerability appeared on the web on 7th April 2014. This highly risked vulnerability enabled attackers to remotely read protected memory contents from Hyper Text Transfer Protocol Secure (HTTPS) sites. In this paper, the authors will review and analyze Heartbleed vulnerability effects on secured websites, a year later (April 2015). To accomplish this, we conducted an analysis on a dataset of 100 Italian public and private sector websites like banks, stock exchanges, Cloud Organizations and services on HTTPS websites, thereby obtained that only 1% of the websites show the vulnerability. However, new vulnerabilities as Padding Oracle on Downgraded Legacy Encryption (POODLE) & Factoring Attack on RSA-Export Keys (FREAK) affect a lot of websites, particularly the websites used as point of accesses of Italian telematics process. We concluded the paper with the analysis of the Cloud risks that are very harmful for the Cloud customers as well as the Cloud venders due to Heartbleed attack
Secure Sockets Layer (SSL), is a cryptographic protocol that provide communication security over the Internet. SSL encrypt the segments of network connections at the Application Layer for the Transport Layer, using asymmetric cryptography for key exchange, symmetric encryption for confidentiality, and message authentication codes for message integrity. SSL secures web services such as banking, online purchases, email and remote access. SSL has been targeted with attacks from the time it was created. Most of these attacks exploit the vulnerabilities present in the services SSL use, such as digital certificates and the web browsers. Attacks on SSL itself have been successful, at least in the context of research, attacks on the services that SSL uses have been successfully exploited in an actual commercial setting; the fact that makes these kinds of attacks extremely dangerous. In this paper, we briefly explain the various attacks like SSL sniffing, MD5 collide certificate, SSL striping, SSL Null prefix, online certificate status protocol (OCSP),change cipher specdropping, KeyExchangeAlgorithm-spoofing, and version rollback attacks. Since most of the discussed attacks target browsers and the way they manage certificates, an evaluation on the rate of success of the SSL attacks when various browsers are used is also presented. We also discuss the origin and the conditions for the attacks to happen successfully. We further discuss in some detail the two very recent attacks BEAST (Browser Exploit Against SSL/TLS) and CRIME (Compression Ratio Info-leak Made Easy).
Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS
2014 IEEE Symposium on Security and Privacy, 2014
TLS was designed as a transparent channel abstraction to allow developers with no cryptographic expertise to protect their application against attackers that may control some clients, some servers, and may have the capability to tamper with network connections. However, the security guarantees of TLS fall short of those of a secure channel, leading to a variety of attacks.
ANALISA IMPLEMENTASI PROTOKOL HTTPS PADA SITUS WEB PERGURUAN TINGGI DI PULAU JAWA
HTTPS protocol offers better data protection than regular HTTP protocol since it utilize cryptography, mainly encryption and authentication mechanism to provide confidentiality and authenticity to packets sent to and from servers. However, not all institutions have properly implemented HTTPS protocol for their web sites. This paper analyzed the implementation of HTTPS protocol for all higher education web sites in Java island. We found that only 28 out of 1505 (1.86%) of all higher education institution who have a domain name have been using HTTPS protocol for their main domain. Furthermore, not all of them have properly implemented HTTPS protocol. We analyzed all 28 domains and we found that 8 out of 28 (28.57%) institutions are still using SSLv3 protocol which is no longer recommended to be used since it's vulnerable to POODLE attack, 9 out of 28 (32.14%) institutions are still using an old algorithm RC4 which is proven to be insecure, 4 out of 28 (14.28%) institutions only support up to TLS 1.0, and 6 out of 28 (21.42%) institutions are still using SSLv2 or reusing same RSA keys thus vulnerable to DROWN attack. Many of the best practices of implementing HTTPS protocol were also neglected. HTTP Strict Transport Security (HSTS) is used by 5 out of 28 (17.8%) institutions and none of them have implemented HTTP Public Key Pinning (HPKP).
Cryptographically verified implementations for TLS
Proceedings of the 15th ACM conference on Computer and communications security - CCS '08, 2008
We intend to narrow the gap between concrete implementations of cryptographic protocols and their verified models. We develop and verify a small functional implementation of the Transport Layer Security protocol (TLS 1.0). We make use of the same executable code for interoperability testing against mainstream implementa- tions, for automated symbolic cryptographic verification, and for automated computational cryptographic verification. We rely
While modern block ciphers, such as AES, have a block size of at least 128 bits, there are many 64-bit block ciphers, such as 3DES and Blowfish, that are still widely supported in Internet security protocols such as TLS, SSH, and IPsec. When used in CBC mode, these ciphers are known to be susceptible to collision attacks when they are used to encrypt around 2 32 blocks of data (the so-called birthday bound). This threat has traditionally been dismissed as impractical since it requires some prior knowledge of the plaintext and even then, it only leaks a few secret bits per gigabyte. Indeed, practical collision attacks have never been demonstrated against any mainstream security protocol, leading to the continued use of 64-bit ciphers on the Internet. In this work, we demonstrate two concrete attacks that exploit collisions on short block ciphers. First, we present an attack on the use of 3DES in HTTPS that can be used to recover a secret session cookie. Second, we show how a similar attack on Blowfish can be used to recover HTTP BasicAuth credentials sent over OpenVPN connections. In our proof-of-concept demos, the attacker needs to capture about 785GB of data, which takes between 19-38 hours in our setting. This complexity is comparable to the recent RC4 attacks on TLS: the only fully implemented attack takes 75 hours. We evaluate the impact of our attacks by measuring the use of 64-bit block ciphers in real-world protocols. We discuss mitigations, such as disabling all 64-bit block ciphers, and report on the response of various software vendors to our responsible disclosure of these attacks.
Safe configuration of TLS connections
2013 IEEE Conference on Communications and Network Security (CNS), 2013
Transport Layer Security (TLS) and its precursor Secure Sockets Layer (SSL) are the most widely deployed protocol to establish secure communication over insecure Internet Protocol (IP) networks. Providing a secure session layer on top of TCP, TLS is frequently the first defense layer encountered by adversaries who try to cause loss of confidentiality by sniffing live traffic or loss of integrity using man-in-the-middle attacks. Despite its wide deployment and evolution over the last 18 years, TLS remains vulnerable to a number of threats at the protocol layer and therefore does not provide strong security out-of-the-box, requiring tweaks to its configuration in order to provide the expected security benefits. This paper provides a summary of the current TLS threat surface together with a validated approach for minimizing the risk of TLS-compromise. The main contributions of this paper include 1) identification of configuration options that together maximize security guarantees in the context of recent TLS exploits and 2) specification of expected flows and automated comparison with observed flows to flag inconsistencies.