How to Backdoor Diffie-Hellman

Total Page:16

File Type:pdf, Size:1020Kb

How to Backdoor Diffie-Hellman How to Backdoor Diffie-Hellman David Wong NCC Group, June 2016 Abstract have pointed an attack on our first contribu- tion, as well as an improvement for the ex- Lately, several backdoors in cryptographic ploitation of our second contribution. This constructions, protocols and implementations work has been updated to reflect these ad- have been surfacing in the wild: Dual-EC in vances. RSA’s B-Safe product, a modified Dual-EC in Juniper’s operating system ScreenOS and a non-prime modulus in the open-source tool 1 Introduction socat. Many papers have already discussed the fragility of cryptographic constructions Around Christmas 2015 Juniper, a networking not using nothing-up-my-sleeve numbers, as hardware company, released an out-of-cycle se- 2 well as how such numbers can be safely picked. curity bulletin . Two vulnerabilities were dis- However, the question of how to introduce a closed without much details to help us grasp backdoor in an already secure, safe and easy the seriousness of the situation. Fortunately, to audit implementation has so far rarely been at this period of the year many researchers researched (in the public). were home with nothing else to do but to solve We present a new way of building a Nobody- this puzzle. By quickly comparing both the But-Us (NOBUS) Diffie-Hellman backdoor by patched and vulnerable binaries, the two is- using a composite modulus with a smooth sues were pinpointed. While one of the vulner- order. We then explain how we were able to abilities was a simple “master”-password im- implement a proof of concept with Socat and plemented at a crucial step of the product’s OpenSSL in order to exploit our backdoor on authentication, the other discovery was a bit the TLS protocol. more subtle: a unique value was modified. More accurately, a number in the source code Keywords: Diffie-Hellman, Ephemeral, was replaced. The introduction of the vulner- DHE, NOBUS, Backdoor, Discrete Logarithm, ability was so simple, and due to the fact that Small Subgroup Attack, Pohlig-Hellman, Pol- the number was stored as a string of hexadec- lard Rho, Factorization, Pollard’s p-1, ECM, imal digits, the trivial use of the UNIX com- Dual-EC, Juniper, socat mand line tool strings was enough to discover it. The special value ended up being a constant Update (December 2016): Dorey et al.1 Archive, Report 2016/999. http : / / eprint . iacr . 1Kristen Dorey, Nicholas Chang-Fong, and Alek- org/2016/999. 2016 sander Essex. Indiscreet Logs: Persistent Diffie- 2https://kb.juniper.net/InfoCenter/index? Hellman Backdoors in TLS. Cryptology ePrint page=content&id=JSA10713 1 Shumow and Ferguson4 at Crypto 2007, which might have been the reason why Juniper gen- erated their own point Q in their implementa- tion of Dual EC. Shortly after that revision, a mysterious update would change that Q point one more time, magically allowing another or- ganization, or person, to access that backdoor in place of the NSA or Juniper. Although the quest to find Juniper’s backdoor Figure 1: The strings of the patched binary and the numerous open questions that arose from that work is a fascinating read by itself5, it is only the introduction of the work you are currently reading. Here we aim to show how secure and strong cryptographic constructions are a single and subtle change away from being your own secretive peep show. On February 1st, 2016, only a few months after Juniper’s debacle, socat published a security advisory of its own6: Figure 2: The strings of the vulnerable binary In the OpenSSL address implemen- tation the hard coded 1024-bit DH p used in the system’s pseudo-random number parameter was not prime. The effec- generator (PRNG) Dual EC, an odd algo- tive cryptographic strength of a key rithm believed to have been backdoored by the exchange using these parameters was NSA3. The PRNG’s core has the ability to pro- weaker than the one one could get vide a Nobody-But-Us (NOBUS) trapdoor: a by using a prime p. Moreover, since secret passage that can only be accessed by the there is no indication of how these pa- people holding the secret key. In our case: the rameters were chosen, the existence elliptic curve discrete logarithm k in the Dual of a trapdoor that makes possible for EC equation Q = [k]P (where P and Q are an eavesdropper to recover the shared the two elliptic curve points used in the foun- secret from a key exchange that uses dation of Dual EC). them cannot be ruled out. Solely the NSA is thought to be in possession In the same vein as Juniper’s problem, a single of that k value, making them the only ones 4 able to climb back to the PRNG’s internal Shumow and Ferguson. On the Possibility of a Back Door in the NIST SP800-90 Dual Ec Prng. state from random outputs, and then able to Crypto 2007. http : / / rump2007 . cr . yp . to / 15 - predict the PRNG’s future states and outputs. shumow.pdf. 2007 The backdoor in Dual EC was pointed out by 5Stephen Checkoway et al. A Systematic Analysis of the Juniper Dual EC Incident. Cryptology ePrint 3Daniel J. Bernstein, Tanja Lange, and Ruben Archive, Report 2016/376. http : / / eprint . iacr . Niederhagen. Dual EC: A Standardized Back Door. org/2016/376. 2016 Cryptology ePrint Archive, Report 2015/767. http: 6http://www.openwall.com/lists/ //eprint.iacr.org/2015/767. 2015 oss-security/2016/02/01/4 2 number was at issue. This time it was the parameters into open-source or closed-source public modulus, an integer used to generate libraries. This work is about generating such the ephemeral Diffie-Hellman keys of both backdoors and implementing them in TLS, parties during socat’s TLS handshakes. This showing how easy and subtle the process is. algorithm had been, contrary to Dual-EC, The working code along with explanations on considered secure from the start. But as it how to reproduce our setup is available on turned out, badly understood as well: as the Github10. Logjam7 paper had demonstrated earlier in the previous year, most servers would use In section 2, we will first briefly talk about Diffie-Hellman key exchanges to perform the several attacks possible on Diffie-Hellman, ephemeral handshakes, and the same servers from small subgroup attacks to Pohlig Hell- would generate their ephemeral keys from man’s algorithm. In section 3 we will introduce hardcoded defaults (often the same ones) our first attempt at a DH backdoor. We will provided by various TLS libraries. The present another DH backdoor in section 4 by paper raised a wave of discussion around how using the ideas of the previous section with a developers should use Diffie-Hellman, at the composite modulus. In section 5 we will see an- same time scaring people away from 1024 bit other method using a composite modulus that DH: “We estimate that even in the 1024-bit allows us to choose a specific generator, allow- case, the computations are plausible given ing us to only modify the modulus value when nation-state resources”. implementing our backdoor. In section 6 we will explain how we implemented the backdoor Securely integrating DH in a protocol is in TLS and how we exploited it. We will then unfortunately not well understood. Defensive see in section 7 how to detect such backdoors approaches are discussed in several RFCs89, and how to prevent them. Eventually we will but few papers so far have taken the point of wrap it all up in section 8. view of the attacker. The combination of the current trend of increasing the bitsize of DH 2 Attacks on Diffie-Hellman parameters with the now old trend of using open source libraries’ defaults to generate and the Discrete Logarithm ephemeral Diffie-Hellman keys would give To attack a Diffie-Hellman key exchange, one opportunist attackers a valid excuse to submit could extract the secret key a from one of the their bigger (more secure) and backdoored a peer’s public key ya = g (mod p). One could then compute the shared key gab (mod p) 7 David Adrian et al. “Imperfect Forward Secrecy: using the other peer’s public key y = gb How Diffie-Hellman Fails in Practice”. In: 22nd ACM b Conference on Computer and Communications Secu- (mod p). rity. https : / / weakdh . org / imperfect - forward - secrecy-ccs15.pdf. Oct. 2015 The naive way to go about this is to compute 8 Eric Rescorla. RFC 2631: Diffie-Hellman Key each power of g (while tracking the exponent) Agreement Method. RFC 2631. https://rfc-editor. org/rfc/rfc2631.txt. 2013. doi: 10.17487/rfc2631 until the public key is found. This is called 9Robert Zuccherato. RFC 2785: Methods for trial multiplication and would need on av- Avoiding the Small-Subgroup Attacks on the Diffie- q erage 2 operations to find a solution (with Hellman Key Agreement Method for S/MIME. RFC 2785. https://rfc-editor.org/rfc/rfc2785.txt. 10https://github.com/mimoo/Diffie-Hellman_ 2013. doi: 10.17487/rfc2785 Backdoor 3 q the order of the base). More efficiently, 2.2 Pohlig-Hellman algorithms that compute discrete logarithm p In 1978, Pohlig and Hellman discovered a in expected q steps like Shank’s baby-step 11 giant-step (deterministic), Pollard rho or shortcut to the discrete logarithm problem : Pollard Kangaroo (both probabilistic) can be if you know the complete factorization of the used. Because of the memory required for order of the group, and all of the factors are rel- baby-step giant-step, Pollard’s algorithms are atively small, then the discrete logarithm can often preferred.
Recommended publications
  • Email Transport Encryption STARTTLS Vs. DANE Vs. MTA-STS
    Email Transport Encryption STARTTLS vs. DANE vs. MTA-STS Delimitation This document deals with the encrypted transport of messages between two email servers. Encryption during transport is crucial for a basic level of security for the exchange of messages. The exchange of messages between an email client and a server or the end-to-end encryption of messages are not covered in this article. If the aim is to create a secure overall system, these aspects should be considered in addition to the recommendations in this article. Initial situation When the first standard for the Simple Mail Transfer Protocol (in short: SMTP) was adopted, encryption of the transport was not included. All messages were exchanged as plain text between the servers. They were thus basically readable for anyone who could tap into the data exchange between the two servers. This only changed with the introduction of the SMTP Service Extensions for Extend SMTP (ESMTP for short), which made it possible to choose encrypted transport as an opportunistic feature of data exchange. Opportunistic, because it had to be assumed that not all servers would be able to handle transport encryption. They should only encrypt when it is opportune; encryption is not mandatory. To indicate the basic ability to encrypt to a sending server, it was agreed that the receiving server should send the keyword STARTTLS at the beginning of an ESMTP transport session. STARTTLS STARTTLS can encrypt the transport between two email servers. The receiving server signals the sending server that it is capable of encrypting after a connection is established and in the ESMTP session.
    [Show full text]
  • MTA STS Improving Email Security.Pdf
    Improving Email Security with the MTA-STS Standard By Brian Godiksen An Email Best Practices Whitepaper CONTENTS Executive Overview 03 Why Does Email Need Encryption in Transit? 04 The Problem with “Opportunistic Encryption” 07 The Anatomy of a Man-in-the-Middle Attack 08 The Next Major Step with Email Encryption: MTA-STS 10 What Steps Should Senders Take to Adopt MTA-STS? 11 About SocketLabs 12 Brian Godiksen Brian has been helping organizations optimize email deliverability since joining SocketLabs in 2011. He currently manages a team of deliverability analysts that consult with customers on best infrastructure practices, including email authentication implementation, bounce processing, IP address warm-up, and email marketing list management. Brian leads the fight against spam and email abuse at SocketLabs by managing compliance across the platform. He is an active participant in key industry groups such as M3AAWG and the Email Experience Council. You can read more of Brian’s content here on the SocketLabs website. ©2019 SocketLabs 2 Executive The Edward Snowden leaks of 2013 opened many peoples’ eyes to the fact that mass surveillance was possible by Overview intercepting and spying on email transmissions. Today, compromised systems, database thefts, and technology breaches remain common fixtures in news feeds around the world. As a natural response, the technology industry is rabidly focused on improving the security and encryption of communications across all platforms. Since those early days of enlightenment, industry experts have discussed and attempted a variety of new strategies to combat “pervasive monitoring” of email channels. While pervasive monitoring assaults can take many forms, the most prominent forms of interference were man-in-the-middle (MitM) attacks.
    [Show full text]
  • A Public-Key Cryptosystem Based on Discrete Logarithm Problem Over Finite Fields 퐅퐩퐧
    IOSR Journal of Mathematics (IOSR-JM) e-ISSN: 2278-5728, p-ISSN: 2319-765X. Volume 11, Issue 1 Ver. III (Jan - Feb. 2015), PP 01-03 www.iosrjournals.org A Public-Key Cryptosystem Based On Discrete Logarithm Problem over Finite Fields 퐅퐩퐧 Saju M I1, Lilly P L2 1Assistant Professor, Department of Mathematics, St. Thomas’ College, Thrissur, India 2Associate professor, Department of Mathematics, St. Joseph’s College, Irinjalakuda, India Abstract: One of the classical problems in mathematics is the Discrete Logarithm Problem (DLP).The difficulty and complexity for solving DLP is used in most of the cryptosystems. In this paper we design a public key system based on the ring of polynomials over the field 퐹푝 is developed. The security of the system is based on the difficulty of finding discrete logarithms over the function field 퐹푝푛 with suitable prime p and sufficiently large n. The presented system has all features of ordinary public key cryptosystem. Keywords: Discrete logarithm problem, Function Field, Polynomials over finite fields, Primitive polynomial, Public key cryptosystem. I. Introduction For the construction of a public key cryptosystem, we need a finite extension field Fpn overFp. In our paper [1] we design a public key cryptosystem based on discrete logarithm problem over the field F2. Here, for increasing the complexity and difficulty for solving DLP, we made a proper additional modification in the system. A cryptosystem for message transmission means a map from units of ordinary text called plaintext message units to units of coded text called cipher text message units. The face of cryptography was radically altered when Diffie and Hellman invented an entirely new type of cryptography, called public key [Diffie and Hellman 1976][2].
    [Show full text]
  • HTTP2 Explained
    HTTP2 Explained Daniel Stenberg Mozilla Corporation [email protected] ABSTRACT credits to everyone who helps out! I hope to make this document A detailed description explaining the background and problems better over time. with current HTTP that has lead to the development of the next This document is available at http://daniel.haxx.se/http2. generation HTTP protocol: HTTP 2. It also describes and elaborates around the new protocol design and functionality, 1.3 License including some implementation specifics and a few words about This document is licensed under the the future. Creative Commons Attribution 4.0 This article is an editorial note submitted to CCR. It has NOT license: been peer reviewed. The author takes full responsibility for this http://creativecommons.org/licenses/by/4.0/ article’s technical content. Comments can be posted through CCR Online. 2. HTTP Today Keywords HTTP 1.1 has turned into a protocol used for virtually everything HTTP 2.0, security, protocol on the Internet. Huge investments have been done on protocols and infrastructure that takes advantage of this. This is taken to the 1. Background extent that it is often easier today to make things run on top of HTTP rather than building something new on its own. This is a document describing http2 from a technical and protocol level. It started out as a presentation I did in Stockholm in April 2014. I've since gotten a lot of questions about the contents of 2.1 HTTP 1.1 is Huge that presentation from people who couldn't attend, so I decided to When HTTP was created and thrown out into the world it was convert it into a full-blown document with all details and proper probably perceived as a rather simple and straight-forward explanations.
    [Show full text]
  • 2.3 Diffie–Hellman Key Exchange
    2.3. Di±e{Hellman key exchange 65 q q q q q q 6 q qq q q q q q q 900 q q q q q q q qq q q q q q q q q q q q q q q q q 800 q q q qq q q q q q q q q q qq q q q q q q q q q q q 700 q q q q q q q q q q q q q q q q q q q q q q q q q q qq q 600 q q q q q q q q q q q q qq q q q q q q q q q q q q q q q q q qq q q q q q q q q 500 q qq q q q q q qq q q q q q qqq q q q q q q q q q q q q q qq q q q 400 q q q q q q q q q q q q q q q q q q q q q q q q q 300 q q q q q q q q q q q q q q q q q q qqqq qqq q q q q q q q q q q q 200 q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q q qq q q qq q q 100 q q q q q q q q q q q q q q q q q q q q q q q q q 0 q - 0 30 60 90 120 150 180 210 240 270 Figure 2.2: Powers 627i mod 941 for i = 1; 2; 3;::: any group and use the group law instead of multiplication.
    [Show full text]
  • Fast Elliptic Curve Cryptography in Openssl
    Fast Elliptic Curve Cryptography in OpenSSL Emilia K¨asper1;2 1 Google 2 Katholieke Universiteit Leuven, ESAT/COSIC [email protected] Abstract. We present a 64-bit optimized implementation of the NIST and SECG-standardized elliptic curve P-224. Our implementation is fully integrated into OpenSSL 1.0.1: full TLS handshakes using a 1024-bit RSA certificate and ephemeral Elliptic Curve Diffie-Hellman key ex- change over P-224 now run at twice the speed of standard OpenSSL, while atomic elliptic curve operations are up to 4 times faster. In ad- dition, our implementation is immune to timing attacks|most notably, we show how to do small table look-ups in a cache-timing resistant way, allowing us to use precomputation. To put our results in context, we also discuss the various security-performance trade-offs available to TLS applications. Keywords: elliptic curve cryptography, OpenSSL, side-channel attacks, fast implementations 1 Introduction 1.1 Introduction to TLS Transport Layer Security (TLS), the successor to Secure Socket Layer (SSL), is a protocol for securing network communications. In its most common use, it is the \S" (standing for \Secure") in HTTPS. Two of the most popular open- source cryptographic libraries implementing SSL and TLS are OpenSSL [19] and Mozilla Network Security Services (NSS) [17]: OpenSSL is found in, e.g., the Apache-SSL secure web server, while NSS is used by Mozilla Firefox and Chrome web browsers, amongst others. TLS provides authentication between connecting parties, as well as encryp- tion of all transmitted content. Thus, before any application data is transmit- ted, peers perform authentication and key exchange in a TLS handshake.
    [Show full text]
  • Making NTRU As Secure As Worst-Case Problems Over Ideal Lattices
    Making NTRU as Secure as Worst-Case Problems over Ideal Lattices Damien Stehlé1 and Ron Steinfeld2 1 CNRS, Laboratoire LIP (U. Lyon, CNRS, ENS Lyon, INRIA, UCBL), 46 Allée d’Italie, 69364 Lyon Cedex 07, France. [email protected] – http://perso.ens-lyon.fr/damien.stehle 2 Centre for Advanced Computing - Algorithms and Cryptography, Department of Computing, Macquarie University, NSW 2109, Australia [email protected] – http://web.science.mq.edu.au/~rons Abstract. NTRUEncrypt, proposed in 1996 by Hoffstein, Pipher and Sil- verman, is the fastest known lattice-based encryption scheme. Its mod- erate key-sizes, excellent asymptotic performance and conjectured resis- tance to quantum computers could make it a desirable alternative to fac- torisation and discrete-log based encryption schemes. However, since its introduction, doubts have regularly arisen on its security. In the present work, we show how to modify NTRUEncrypt to make it provably secure in the standard model, under the assumed quantum hardness of standard worst-case lattice problems, restricted to a family of lattices related to some cyclotomic fields. Our main contribution is to show that if the se- cret key polynomials are selected by rejection from discrete Gaussians, then the public key, which is their ratio, is statistically indistinguishable from uniform over its domain. The security then follows from the already proven hardness of the R-LWE problem. Keywords. Lattice-based cryptography, NTRU, provable security. 1 Introduction NTRUEncrypt, devised by Hoffstein, Pipher and Silverman, was first presented at the Crypto’96 rump session [14]. Although its description relies on arithmetic n over the polynomial ring Zq[x]=(x − 1) for n prime and q a small integer, it was quickly observed that breaking it could be expressed as a problem over Euclidean lattices [6].
    [Show full text]
  • The Discrete Log Problem and Elliptic Curve Cryptography
    THE DISCRETE LOG PROBLEM AND ELLIPTIC CURVE CRYPTOGRAPHY NOLAN WINKLER Abstract. In this paper, discrete log-based public-key cryptography is ex- plored. Specifically, we first examine the Discrete Log Problem over a general cyclic group and algorithms that attempt to solve it. This leads us to an in- vestigation of the security of cryptosystems based over certain specific cyclic × groups: Fp, Fp , and the cyclic subgroup generated by a point on an elliptic curve; we ultimately see the highest security comes from using E(Fp) as our group. This necessitates an introduction of elliptic curves, which is provided. Finally, we conclude with cryptographic implementation considerations. Contents 1. Introduction 2 2. Public-Key Systems Over a Cyclic Group G 3 2.1. ElGamal Messaging 3 2.2. Diffie-Hellman Key Exchanges 4 3. Security & Hardness of the Discrete Log Problem 4 4. Algorithms for Solving the Discrete Log Problem 6 4.1. General Cyclic Groups 6 × 4.2. The cyclic group Fp 9 4.3. Subgroup Generated by a Point on an Elliptic Curve 10 5. Elliptic Curves: A Better Group for Cryptography 11 5.1. Basic Theory and Group Law 11 5.2. Finding the Order 12 6. Ensuring Security 15 6.1. Special Cases and Notes 15 7. Further Reading 15 8. Acknowledgments 15 References 16 1 2 NOLAN WINKLER 1. Introduction In this paper, basic knowledge of number theory and abstract algebra is assumed. Additionally, rather than beginning from classical symmetric systems of cryptog- raphy, such as the famous Caesar or Vigni`ere ciphers, we assume a familiarity with these systems and why they have largely become obsolete on their own.
    [Show full text]
  • Sieve Algorithms for the Discrete Logarithm in Medium Characteristic Finite Fields Laurent Grémy
    Sieve algorithms for the discrete logarithm in medium characteristic finite fields Laurent Grémy To cite this version: Laurent Grémy. Sieve algorithms for the discrete logarithm in medium characteristic finite fields. Cryptography and Security [cs.CR]. Université de Lorraine, 2017. English. NNT : 2017LORR0141. tel-01647623 HAL Id: tel-01647623 https://tel.archives-ouvertes.fr/tel-01647623 Submitted on 24 Nov 2017 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. AVERTISSEMENT Ce document est le fruit d'un long travail approuvé par le jury de soutenance et mis à disposition de l'ensemble de la communauté universitaire élargie. Il est soumis à la propriété intellectuelle de l'auteur. Ceci implique une obligation de citation et de référencement lors de l’utilisation de ce document. D'autre part, toute contrefaçon, plagiat, reproduction illicite encourt une poursuite pénale. Contact : [email protected] LIENS Code de la Propriété Intellectuelle. articles L 122. 4 Code de la Propriété Intellectuelle. articles L 335.2- L 335.10 http://www.cfcopies.com/V2/leg/leg_droi.php
    [Show full text]
  • Dynamic Public Key Certificates with Forward Secrecy
    electronics Article Dynamic Public Key Certificates with Forward Secrecy Hung-Yu Chien Department of Information Management, National Chi Nan University, Nantou 54561, Taiwan; [email protected] Abstract: Conventionally, public key certificates bind one subject with one static public key so that the subject can facilitate the services of the public key infrastructure (PKI). In PKI, certificates need to be renewed (or revoked) for several practical reasons, including certificate expiration, private key breaches, condition changes, and possible risk reduction. The certificate renewal process is very costly, especially for those environments where online authorities are not available or the connection is not reliable. A dynamic public key certificate (DPKC) facilitates the dynamic changeover of the current public–private key pairs without renewing the certificate authority (CA). This paper extends the previous study in several aspects: (1) we formally define the DPKC; (2) we formally define the security properties; (3) we propose another implementation of the Krawczyk–Rabin chameleon-hash- based DPKC; (4) we propose two variants of DPKC, using the Ateniese–Medeiros key-exposure-free chameleon hash; (5) we detail two application scenarios. Keywords: dynamic public key certificate; chameleon signature; certificate renewal; wireless sensor networks; perfect forward secrecy 1. Introduction Citation: Chien, H.-Y. Dynamic Certificates act as the critical tokens in conventional PKI systems. With the trust Public Key Certificates with Forward of the CA, a
    [Show full text]
  • SSL Checklist for Pentesters
    SSL Checklist for Pentesters Jerome Smith BSides MCR, 27th June 2014 # whoami whoami jerome • Pentester • Author/trainer – Hands-on technical – Web application, infrastructure, wireless security • Security projects – Log correlation – Dirty data – Incident response exercises • Sysadmin • MSc Computing Science (Dist) • www.exploresecurity.com | @exploresecurity Introduction • Broad review of SSL/TLS checks – Viewpoint of pentester – Pitfalls – Manually replicating what tools do (unless you told the client that SSL Labs would be testing them ) – Issues to consider reporting (but views are my own) • While SSL issues are generally low in priority, it’s nice to get them right! • I’m not a cryptographer: this is all best efforts SSLv2 • Flawed, e.g. no handshake protection → MITM downgrade • Modern browsers do not support SSLv2 anyway – Except for IE but it’s disabled by default from IE7 – That mitigates the risk these days – http://en.wikipedia.org/wiki/Transport_Layer_Security#W eb_browsers • OpenSSL 1.0.0+ doesn’t support it – Which means SSLscan won’t find it – General point: tools that dynamically link to an underlying SSL library in the OS can be limited by what that library supports SSLv2 • Same scan on different OpenSSL versions: SSLv2 • testssl.sh warns you – It can work with any installed OpenSSL version • OpenSSL <1.0.0 s_client -ssl2 switch – More on this later • Recompile OpenSSL – http://blog.opensecurityresearch.com/2013/05/fixing-sslv2-support- in-kali-linux.html • SSLyze 0.7+ is statically linked – Watch out for bug https://github.com/iSECPartners/sslyze/issues/73
    [Show full text]
  • Sicherheit in Kommunikationsnetzen (Network Security)
    Sicherheit in Kommunikationsnetzen (Network Security) Transport Layer Security Dr.-Ing. Matthäus Wander Universität Duisburg-Essen Transport Layer Security (TLS) PrivateTLS data Web browser Web server ∙ Cryptographic protocol ∘ Provides security on top of reliable transport (TCP) ∘ Used to secure HTTP, SMTP, IMAP, XMPP and others ∙ Security goals ∘ Authentication of server and optionally client ∘ Data integrity (no manipulation of data) ∘ Confidentiality (encryption) Universität Duisburg-Essen Matthäus Wander 2 Verteilte Systeme History ∙ Predecessor: Secure Sockets Layer (SSL) ∘ Developed by Netscape for HTTPS (= HTTP + SSL) ∙ 1994: SSL 2.0 ∘ Insecure, major security weaknesses ∙ 1995: SSL 3.0 ∘ Insecure, deprecated since 2015 (RFC 7568) ∙ 1999: TLS 1.0, minor improvements to SSL 3.0 ∘ Standardization and further development by IETF Universität Duisburg-Essen Matthäus Wander 3 Verteilte Systeme History ∙ 2003: TLS Extensions ∘ New features or security mechanisms (e.g. Encrypt-then-MAC, RFC 7366) ∙ 2006: TLS 1.1 ∘ Security improvements ∙ 2008: TLS 1.2 Presented in this lecture ∘ Added new or replaced old cryptographic algorithms ∙ TLS 1.3 is work in progress as of 2017 ∘ Outlook: new handshake and other major changes Universität Duisburg-Essen Matthäus Wander 4 Verteilte Systeme Protocol Overview Application Layer (e.g. HTTP) Handshake Change Cipher Application Alert Protocol Protocol Spec Protocol Data Protocol Record Protocol Transport Layer (e.g. TCP) ∙ TLS consists of two layers: ∘ Handshake Protocol and other protocols ∘ Record Protocol
    [Show full text]