DOCSLIB.ORG

Let's Encrypt

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Let's Encrypt Let’s Encrypt Die neue Sicherheit für Jeden Inhaltsverzeichnis 1 Let’s Encrypt 1 1.1 Überblick ............................................... 1 1.2 Beteiligte ............................................... 1 1.3 Technik ................................................ 2 1.3.1 Protokoll ........................................... 2 1.3.2 Server-Implementierung ................................... 2 1.3.3 Clients ............................................ 2 1.4 Geschichte und Zeitplan ....................................... 3 1.5 Siehe auch .............................................. 4 1.6 Weblinks ............................................... 4 1.7 Quellen ................................................ 4 2 Extended-Validation-Zertifikat 6 2.1 Motivation .............................................. 7 2.2 Benutzerschnittstelle ......................................... 7 2.2.1 Browserunterstützung .................................... 7 2.3 Vergabekriterien ........................................... 7 2.4 Weblinks ............................................... 8 2.5 Einzelnachweise ............................................ 8 3 X.509 9 3.1 Geschichte .............................................. 9 3.2 Zertifikate ............................................... 9 3.2.1 Struktur eines X.509-v3-Zertifikats ............................. 9 3.2.2 Erweiterungen ........................................ 10 3.2.3 Dateinamenserweiterungen für Zertifikate .......................... 11 3.3 Beispiel für ein X.509-Zertifikat ................................... 11 3.4 Literatur ............................................... 11 3.5 Weblinks ............................................... 12 4 Transport Layer Security 13 4.1 TLS in der Praxis ........................................... 13 4.1.1 Versionen ........................................... 14 i ii INHALTSVERZEICHNIS 4.2 Geschichte .............................................. 14 4.3 Funktionsweise ............................................ 15 4.3.1 TLS-Protokolle im Protokollstapel .............................. 15 4.3.2 TLS Record Protocol ..................................... 16 4.3.3 TLS Handshake Protocol ................................... 16 4.3.4 TLS Change Cipher Spec Protocol .............................. 17 4.3.5 TLS Alert Protocol ...................................... 18 4.3.6 TLS Application Data Protocol ............................... 18 4.3.7 Berechnung des Master Secrets ............................... 18 4.4 Sicherheit ............................................... 18 4.4.1 Padding-Oracle-Angriffe ................................... 18 4.4.2 BEAST ............................................ 18 4.4.3 Kompressionsangriffe .................................... 19 4.4.4 Downgrade auf Exportverschlüsselung ............................ 19 4.4.5 Implementierungsfehler ................................... 19 4.5 Vor- und Nachteile .......................................... 20 4.6 Implementierungen .......................................... 20 4.7 Siehe auch .............................................. 20 4.8 Literatur ............................................... 20 4.9 Weblinks ............................................... 21 4.10 Einzelnachweise ............................................ 21 5 Hypertext Transfer Protocol Secure 23 5.1 Nutzen ................................................ 23 5.2 Technik ................................................ 23 5.3 Client-Verarbeitung .......................................... 23 5.3.1 Varianten der HTTPS-Anwahl ................................ 24 5.3.2 Vorinstallierte Zertifikate ................................... 25 5.4 Server-Betrieb ............................................ 25 5.4.1 Zertifikat ........................................... 25 5.4.2 IP-Adressen bei mehreren Domains ............................. 26 5.4.3 Einbindung .......................................... 26 5.4.4 Umstellung .......................................... 27 5.4.5 Leistung ........................................... 27 5.5 Angriffe und Schwachstellen ..................................... 28 5.5.1 Verschlüsselung ....................................... 28 5.5.2 Zertifikatsystem ....................................... 28 5.6 Spezifikationen ............................................ 29 5.7 Weblinks ............................................... 29 5.8 Einzelnachweise ............................................ 29 5.9 Text- und Bildquellen, Autoren und Lizenzen ............................. 30 5.9.1 Text .............................................. 30 INHALTSVERZEICHNIS iii 5.9.2 Bilder ............................................. 30 5.9.3 Inhaltslizenz .......................................... 31 Kapitel 1 Let’s Encrypt Let’s Encrypt (englisch, „Lasst uns verschlüsseln“) ist eine Zertifizierungsstelle, die Ende 2015 in Betrieb gegangen ist und kostenlose X.509-Zertifikate für Transport Layer Security (TLS) anbietet. Dabei ersetzt ein automatisierter Prozess die bisher gängigen komplexen händischen Vorgänge bei der Erstellung, Validierung, Signierung, Einrichtung und Erneuerung von Zertifikaten für verschlüsselte Websites.[1][2] 1.1 Überblick Ziel des Projekts ist es, verschlüsselte Verbindungen im World Wide Web zum Normalfall zu machen. Indem unter anderem Zahlung, Webserverkonfiguration, Validierungs-E-Mails und die Sorge um abgelaufene Zertifikate über- flüssig werden, sollen Aufwand für Einrichtung und Pflege von TLS-Verschlüsselung deutlich gesenkt werden.[3] Auf einem Linux-Webserver soll das Ausführen von nur zwei Befehlen genügen, um binnen 20 bis 30 Sekunden HTTPS-Verschlüsselung einzurichten, Zertifikate anzufordern und zu installieren.[4][5] Bei aktuellen Bestrebungen von großen Webbrowser-Projekten, unverschlüsseltes HTTP als überholt zu erklären und zukünftig davor zu warnen oder die Unterstützung einzuschränken, wird unter anderem auf die Verfügbarkeit von Let’s Encrypt gesetzt.[6][7] Dem Projekt wird das Potenzial zugesprochen, die standardmäßige Verschlüsselung des gesamten Web zu erreichen.[8] Es werden sogenannte Domain-Validation-Zertifikate ausgestellt. Organization-Validation- und Extended-Validation- Zertifikate werden nicht angeboten.[9] Um sowohl die eigene Vertrauenswürdigkeit, als auch gegen Angriffe und Manipulationsversuche zu schützen, soll auf größtmögliche Transparenz gesetzt werden. Dazu werden zum Beispiel regelmäßig Transparenzberichte veröffentlicht,[10] alle ACME-Transaktionen öffentlich protokolliert (u.a. mit Certificate Transparency) und möglichst viel auf offene Standards und freie Software gesetzt.[4] Der Name der Zertifizierungsstellen-Software „Boulder“ (englisch, „[Fels-]Brocken“) ist eine Anspielung auf ein Produkt der fiktiven Firma ACME (englisch acme ‚Gipfel‘, ‚Höhepunkt‘) aus den Trickfilmen um Road Runner und Wile E. Coyote. 1.2 Beteiligte Let’s Encrypt ist ein von der gemeinnützigen Internet Security Research Group (ISRG) angebotener Dienst. Haupt- sponsoren sind unter anderem die Electronic Frontier Foundation (EFF), die Mozilla Foundation, Akamai, Google Chrome und Cisco Systems. Weitere Beteiligte sind die Zertifizierungsstelle IdenTrust, die University of Michigan (U-M), die Stanford Law School, die Linux Foundation[11] sowie Stephen Kent von Raytheon/BBN Technologies und Alex Polvi von CoreOS.[4] 1 2 KAPITEL 1. LET’S ENCRYPT 1.3 Technik Let’s Encrypt besitzt ein RSA-Stammzertifikat, das in einem Hardware-Sicherheitsmodul verwahrt wird und nicht direkt verwendet wird. Es soll später durch ein ECDSA-Zertifikat ersetzt werden. Damit werden zwei Zwischen- zertifikate signiert, welche durch die Zertifizierungsstelle IdenTrust gegengezeichnet werden.[12] Eines davon dient dann zur Signierung der ausgestellten Zertifikate, das andere als Ersatz bei Problemen mit dem ersten. Durch die IdenTrust-Signatur können die ausgestellten Zertifikate in großen Webbrowsern über die vorinstallierten Stammzer- tifizierungsstellen geprüft werden. So werden Let’s-Encrypt-Zertifikate auf Client-Seite von Anfang an in der Regel ohne weiteres akzeptiert.[13] Längerfristig sollen direkt Let’s-Encrypt-Zertifikate in Anwendungen vorinstalliert wer- den. 1.3.1 Protokoll Das zur Automatisierung der Zertifizierung genutzte Challenge-Response-Verfahren heißt Automated Certificate Management Environment (ACME). Dabei werden verschiedene Anfragen an den Webserver der zu zertifizieren- den Domain gestellt. Anhand gegebenenfalls darauf erfolgenden passenden Rückmeldungen wird sichergestellt, dass der Antragsteller die Domain kontrolliert („domain validation“). Auf dem Server-System müssen diese Anfragen korrekt beantwortet werden. Dazu bietet das Protokoll verschie- dene Möglichkeiten. Bei einer wird dazu von der ACME-Client-Software ein besonders konfigurierter TLS-Server eingerichtet, der mittels Server Name Indication auf besondere Anfragen der Zertifizierungsstelle antwortet (Domain- Validierung mittels Server Name Indication, DVSNI). Dieses Verfahren wird allerdings nur für eine erste Zertifikats- ausstellung für eine Domain akzeptiert (sogenanntes „trust on first use“, TOFU – Vertrauen bei erster Benutzung). Danach kommt die alternative Validierung über ein bestehendes Zertifikat zum Einsatz. Bei Verlust der Kontrol- le über ein bereits ausgestelltes Zertifikat muss daher ein Zertifikat von einem Drittanbieter erworben werden, um wieder ein Let’s-Encrypt-Zertifikat zu erhalten. Die Validierungsverfahren werden mehrmals über verschiedene Netzwerkpfade durchgeführt. Zur Erschwerung von DNS-Spoofing ist die Prüfung von DNS-Einträgen von mehreren
Load more

Recommended publications
  • Measuring the Rapid Growth of HSTS and HPKP Deployments
    Measuring the Rapid Growth of HSTS and HPKP Deployments Ivan Petrov∗ Denis Peskov∗ Gregory Coard∗ Taejoong Chungy David Choffnesy Dave Levin∗ Bruce M. Maggsz Alan Mislovey Christo Wilsony ∗ University of Maryland yNortheastern University zDuke University & Akamai Technologies ABSTRACT version of the website, thereby exposing future commu- A basic man-in-the-middle attack to bypass HTTPS strips nication to the MiTM attacker, as well. Second, if an the “s” off of an “https://” URL, thereby forcing the client attacker is able to have a certificate created in someone to effectively downgrade to an insecure connection. To ad- else's name, the attacker can impersonate that victim dress such crude attacks, the HSTS (HTTP Strict Transport domain. Security) protocol was recently introduced, which instructs Both of these attacks completely sidestep the protec- clients to preemptively (or at time of first acquire) load a tions that TLS seeks to provide to its users. To address list of domains to whom to connect strictly via HTTPS. In a these concerns, two recent additions to HTTPS have similar vein, the HPKP (HTTP Public Key Pinning) protocol been introduced. We describe them in detail in Sec- has clients obtain a set of public keys; if in future visits to tion 2, but at a high level: the website the certificate chain does not include any of those • HTTP Strict Transport Security public keys, the client is supposed to reject the connection. (HSTS) [10] addresses SSL stripping attacks by Both HSTS and HPKP are relatively new additions to the informing clients which domains it should connect web’s PKI that have seen a sudden surge in deployment in to strictly over HTTPS (i.e., if presented with an the last couple of years (we observe an order of magnitude http URL to one of these domains, they should greater deployment than a 2015 study of HSTS/HPKP).
    [Show full text]
  • Comptia Security+ 501
    CompTIA Security+ 501 CompTIA Security+ SY0-501 Instructor: Ron Woerner, CISSP, CISM CompTIA Security+ Domain 6 – Cryptography & PKI 6.4 Given a scenario, implement public key infrastructure Cybrary - Ron Woerner 1 CompTIA Security+ 501 6.4 Public-Key Infrastructure (PKI) ● Components ● Types of certificates ○ Public / Private Key ○ User ○ Certificate ○ Root ○ CA ○ Wildcard ○ CRL ○ SAN ○ Code signing ● Concepts ○ Self-signed ○ Online vs Offline CA ○ Machine/computer ○ Stapling ○ Domain validation ○ Pinning ○ Trust model ● Certificate formats ○ Key escrow ○ Certificate chaining Public and Private Keys ● Encrypt a document with the recipient’s public key. Only their private key needs to be kept secret and only it can decrypt the message ● The sender’s private key is used to sign the message Cybrary - Ron Woerner 2 CompTIA Security+ 501 PKI Components Public Key Infrastructure ● Solves the issues with key management ● A set of roles, policies, and procedures needed to manage public- key(asymmetric) encryption ● The process of creating, managing, distributing, storing, using, and revoke keys and digital certificates. ● Public Key Infrastructure X.509 (PKIX) is the working group formed by the IETF to develop standards and models PKI PKI Components - Digital Certificate ● A digitally signed block of data used to prove the ownership of a public key issued by a Certificate Authority ● Includes ○ information about the key, ○ information about the identity of its owner (called the subject), ○ and the digital signature of an entity that has verified the certificate's contents (called the issuer) ● X.509 v3 standard defines the certificate formats and fields for public keys. Cybrary - Ron Woerner 3 CompTIA Security+ 501 Digital Certificate Components X.509 Certificate Types ● Root certificates: for root authorities.
    [Show full text]
  • An Empirical Analysis of Email Delivery Security
    Neither Snow Nor Rain Nor MITM . An Empirical Analysis of Email Delivery Security Zakir Durumeric† David Adrian† Ariana Mirian† James Kasten† Elie Bursztein‡ Nicolas Lidzborski‡ Kurt Thomas‡ Vijay Eranti‡ Michael Bailey§ J. Alex Halderman† † University of Michigan ‡ Google, Inc. § University of Illinois, Urbana Champaign {zakir, davadria, amirian, jdkasten, jhalderm}@umich.edu {elieb, nlidz, kurtthomas, vijaye}@google.com [email protected] ABSTRACT tolerate unprotected communication at the expense of user security. The SMTP protocol is responsible for carrying some of users’ most Equally problematic, users face a medium that fails to alert clients intimate communication, but like other Internet protocols, authen- when messages traverse an insecure path and that lacks a mechanism tication and confidentiality were added only as an afterthought. In to enforce strict transport security. this work, we present the first report on global adoption rates of In this work, we measure the global adoption of SMTP security SMTP security extensions, including: STARTTLS, SPF, DKIM, and extensions and the resulting impact on end users. Our study draws DMARC. We present data from two perspectives: SMTP server from two unique perspectives: longitudinal SMTP connection logs configurations for the Alexa Top Million domains, and over a year spanning from January 2014 to April 2015 for Gmail, one of the of SMTP connections to and from Gmail. We find that the top mail world’s largest mail providers; and a snapshot of SMTP server providers (e.g., Gmail, Yahoo,
    [Show full text]
  • Introduction À La Sécurité Des Systèmes D'informations
    Université de Paris Saclay Polytech Paris Saclay – Département d’informatique Introduction à la sécurité des systèmes d’informations Document réalisé par : Polytech Paris Saclay Département d’informatique Université Paris Saclay Maison de l'Ingénieur Bâtiment 620 91405 Orsay Cedex Gilles Soufflet, Ingénieur Système Version janvier 2020 Université de Paris Saclay Sécurité informatique Polytech Paris Saclay – Département d’informatique Table des matières 1 Avant-propos ________________________________________________________________ 7 2 Notions de cryptographie _____________________________________________________ 10 2.1 Introduction _________________________________________________________________ 10 2.1.1 Principe de Kerckhoffs _______________________________________________________________ 10 2.2 Fonctions de hachage __________________________________________________________ 11 2.2.1 MD5 _____________________________________________________________________________ 11 2.2.2 SHA-1 ____________________________________________________________________________ 12 2.2.3 SHA-2 ____________________________________________________________________________ 12 2.2.4 SHA-3 ____________________________________________________________________________ 13 2.2.5 Whirpool __________________________________________________________________________ 13 2.3 Cryptographie à masque jetable _________________________________________________ 13 2.4 Cryptographie symétrique ou à clé secrète ________________________________________ 14 2.4.1 Chiffrement par bloc _________________________________________________________________
    [Show full text]
  • State of the SSL/ TLS Industry Where Are We Today / Future Trends & Changes by Jay Schiavo
    State of the SSL/ TLS Industry Where Are We Today / Future Trends & Changes By Jay Schiavo © 2016 Entrust Datacard Corporation. All rights reserved. AGENDA • SSL/TLS History • State of the Industry Today • Technologies to Consider • Questions? 2 © 2016 Entrust Datacard Corporation. All rights reserved. SSL/TLS History 3 © 2016 Entrust Datacard Corporation. All rights reserved. SSL MARKET HISTORY 1998 2005 2012 2016 • VeriSign, Entrust, • VeriSign (acquired • Symantec (acquired • Symantec (acquired Thawte, GlobalSign Thawte), Entrust, Thawte and Thawte and GeoTrust, Comodo, GeoTrust), Entrust, GeoTrust), Entrust, • OV SSL GoDaddy Comodo, GoDaddy, Comodo, GoDaddy, Digicert, GlobalSign Digicert, GlobalSign, • E-Commerce • OV SSL, DV SSL Let’s Encrypt, AWS • EV SSL, OV SSL, DV • No governance • E-Commerce and SSL, Multi-Domain • EV SSL, OV SSL, DV protecting sensitive SSL, Cert Mgmt SSL, Multi-Domain data SSL, Cert Mgmt, • E-Commerce and Other Services • CA/Browser Forum protecting sensitive data, Logins, • Encryption Webmail everywhere • EV & SSL Baseline • Browsers enforcing Reqs proper SSL issuance and deployment © Entrust Datacard Corporation. All rights reserved. CHANGING TECHNOLOGIES Endured three certificate-based migrations 1. MD2 and MD5 to SHA-1 2. Small RSA keys to 2048-bit keys or larger 3. SHA-1 to SHA-256 • Additionally: – Encryption levels have changed from 40 bit to 128 bit to 256 bit – SSL protocol to TLS protocol (current version is 1.2) • SSL 2.0 and 3.0 no longer supported in modern browsers • TLS 1.0 and 1.1 are showing some cracks • TLS 1.2 is most secure protocol • TLS 1.3 has not yet been released • What’s next – ECC, RSA 3072, CT for all TLS/SSL © Entrust Datacard Corporation.
    [Show full text]
  • To Pin Or Not to Pin—Helping App Developers Bullet Proof Their TLS
    To Pin or Not to Pin—Helping App Developers Bullet Proof Their TLS Connections Marten Oltrogge and Yasemin Acar, Leibniz Universität Hannover; Sergej Dechand and Matthew Smith, Universität Bonn; Sascha Fahl, Fraunhofer FKIE https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/oltrogge This paper is included in the Proceedings of the 24th USENIX Security Symposium August 12–14, 2015 • Washington, D.C. ISBN 978-1-939133-11-3 Open access to the Proceedings of the 24th USENIX Security Symposium is sponsored by USENIX To Pin or Not to Pin Helping App Developers Bullet Proof Their TLS Connections Marten Oltrogge, Yasemin Acar Sergej Dechand, Matthew Smith DCSEC, Leibniz University Hannover USECAP, University Bonn oltrogge,[email protected] dechand, [email protected] Sascha Fahl FKIE, Fraunhofer [email protected] Abstract information and deploy the transport layer security protocol (TLS) to protect data in transit. Previous For increased security during TLS certificate valida- research uncovered security issues with TLS in mo- tion, a common recommendation is to use a vari- bile apps [7, 8, 9, 2, 22] that highlight that developers ation of pinning. Especially non-browser software have problems with implementing correct certificate developers are encouraged to limit the number of validation while users are challenged by TLS intersti- trusted certificates to a minimum, since the default tials. Furthermore, the default TLS implementation CA-based approach is known to be vulnerable to se- on Android receives criticism [24, 18]: Adopted from rious security threats. web-browsers, default TLS certificate validation re- The decision for or against pinning is always a trade- lies on a huge number of root CAs pre-installed on off between increasing security and keeping mainte- all Android devices [24].
    [Show full text]
  • Applied Crypto Hardening
    Applied Crypto Hardening Wolfgang Breyha, David Durvaux, Tobias Dussa, L. Aaron Kaplan, Florian Mendel, Christian Mock, Manuel Koschuch, Adi Kriegisch, Ulrich Pöschl, Ramin Sabet, Berg San, Ralf Schlatterbeck, Thomas Schreck, Alexander Würstlein, Aaron Zauner, Pepi Zawodsky (University of Vienna, CERT.be, KIT-CERT, CERT.at, A-SIT/IAIK, coretec.at,FH Campus Wien, VRVis, MilCERT Austria, A-Trust, Runtux.com,Friedrich-Alexander University Erlangen-Nuremberg, azet.org, maclemon.at) April 25, 2017 Contents 1. Abstract 5 1.1. Acknowledgements ........................................ 6 2. Introduction 8 2.1. Audience .............................................. 8 2.2. Related publications ........................................ 8 2.3. How to read this guide ....................................... 8 2.4. Disclaimer and scope ........................................ 9 2.4.1. Scope ............................................ 10 2.5. Methods ............................................... 11 3. Practical recommendations 12 3.1. Webservers ............................................. 12 3.1.1. Apache ........................................... 12 3.1.2. lighttpd ........................................... 13 3.1.3. nginx ............................................ 14 3.1.4. Cherokee .......................................... 15 3.1.5. MS IIS ............................................ 17 3.2. SSH ................................................. 20 3.2.1. OpenSSH .......................................... 20 3.2.2. Cisco ASA .........................................
    [Show full text]
  • Guidelines Towards Secure SSL Pinning in Mobile Applications
    Sesion´ VII: Cifrado Guidelines Towards Secure SSL Pinning in Mobile Applications F.J. Ram´ırez-Lopez,´ A. J. Varela-Vaca, J. Ropero, A. Carrasco Universidad de Sevilla, Spain fframirez4, ajvarela, jropero, [email protected] Resumen—Security is a major concern in web applications a good practice guide for all the mobile application developers for so long, but it is only recently that the use of mobile and users. applications has reached the level of web services. This way, The paper is organized as follows. Section II deals with we are taking OWASP Top 10 Mobile as our starting point to secure mobile applications. Insecure communication is one OWASP mobile recommendations. Section III introduces SSL of the most important topics to be considered. In fact, many validations and their possible vulnerabilities. Section IV offers mobile applications do not even implement SSL/TLS validations solutions to SSL pinning bypass and shows a case of use. or may have SSL/TLS vulnerabilities. This paper explains how Finally, Section IV presents the conclusions of the paper. an application can be fortified using secure SSL pinning, and offers a three-step process as an improvement of OWASP Mobile recommendations to avoid SSL pinning bypassing. Therefore, II. OWASP MOBILE RECOMMENDATIONS following the process described in this paper, mobile application developers may establish a secure SSL/TLS communication. OWASP is the worldwide organization responsible for Index Terms—SSL pinning, security, mobile applications, generating a standard for security in web applications [10]. certificate, OWASP This way, we can find several sources of information and Tipo de contribucion:´ Investigacion´ original methodologies in the OWASP documentation.
    [Show full text]
  • Web of Trust Vs Certificate Authority
    Web Of Trust Vs Certificate Authority Which Monte socialising so malapropos that Alton explored her workers? Caressive Costa jesses invaluably Konstantinwhile Bengt festers, always hisacknowledges flow-ons inputs his thwartcatholicized flash-backs deep. fierily, he hiking so drudgingly. Waterproofed What good a chain you trust SSLcom. This means that dental Root CA certificate installed in your stupid Store floor is used to make API calls to justice above three domains has long be changed over from. A border of trust pay a linked validation path become a root CA that serves as simple trust. Digital Certificates Who radiate You Trust Trend Micro. Security with HTTPS and SSL Android Developers. What interest the Certificate Chain a Trust Keyfactor. 509 certificate which means usually signed by a certificate authority CA Web clients such as browsers trust a craft of these CAs which welcome all create. Certificate Authorities and issuing certificates A Certificate Authority CA is database entity she is trusted to generate certificates for third parties. PKI Concepts CompTIA Security SY0-501 64. Trust Models in medicine Key Infrastructure Krishi Sanskriti. In cryptography a web of trust to a concept used in PGP GnuPG and other. Trust model Certificate Authority Service Google Cloud. These intermediate CAs are reveal the ones that often your web server's certificate If your certificate is signed by different intermediate CA you after to import the root. Learn about SSL chain the trust and why fight's so important. Any applications users or computers that trust their Root CA trust any certificates issued by the CA hierarchy The Issuing CA is a CA that issues certificates to end.
    [Show full text]
  • “I Have No Idea What I'm Doing”
    “I Have No Idea What I’m Doing” - On the Usability of Deploying HTTPS Katharina Krombholz, Wilfried Mayer, Martin Schmiedecker, and Edgar Weippl, SBA Research https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/krombholz This paper is included in the Proceedings of the 26th USENIX Security Symposium August 16–18, 2017 • Vancouver, BC, Canada ISBN 978-1-931971-40-9 Open access to the Proceedings of the 26th USENIX Security Symposium is sponsored by USENIX “I Have No Idea What I’m Doing” – On the Usability of Deploying HTTPS Katharina Krombholz Wilfried Mayer Martin Schmiedecker Edgar Weippl SBA Research SBA Research SBA Research SBA Research Abstract and suspectible to a broad array of possible attacks (e.g., Heartbleed [3] and DROWN [11]). Additionally, Protecting communication content at scale is a difficult human-centric studies [20] have shown that warnings task, and TLS is the protocol most commonly used to are still clicked through and that users have little to no do so. However, it has been shown that deploying it understanding regarding the implications of visiting a in a truly secure fashion is challenging for a large frac- website without a valid certificate. Even worse, a large tion of online service operators. While Let’s Encrypt number of services and websites still refrains from using was specifically built and launched to promote the adop- TLS by default for all communication channels despite tion of HTTPS, this paper aims to understand the rea- all efforts in propagating the use of encryption. While sons for why it has been so hard to deploy TLS correctly the initiative Let’s Encrypt was specifically launched to and studies the usability of the deployment process for offer free certificates that are trusted by all browsers, it is HTTPS.
    [Show full text]
  • Breaking Best Practice Protection of the TLS Protocol in an Android
    Introduction Breaking best practice protection of the TLS protocol in an Android environment 2020-05-11 Version 1.0 Author Supervisor C.A.L. Mandjes F. de Korte Master student Radboud University Northwave Red team [email protected] [email protected] Supervisor Second reader Prof. dr. E. Verheul Dr. ir. E. Poll Radboud University Radboud University [email protected] [email protected] 1 Introduction Abstract Northwave’s Red team performs penetration testing on Android applications for its customers. As part of this test, the tester analyzes the data which is being transmitted between the application and its backend server. However, many applications are using the Transport Layer Security (TLS) protocol, which is an encryption protocol, with the certificate pinning technique implemented. In order to set up a man-in-the-middle attack, Northwave was using a tool called the Android-SSL-Trustkiller. This tool disables the certificate pinning technique so that a man- in-the-middle position can be deployed. However, the Android-SSL-Trustkiller is not working when the targeted Android application is using the SafetyNet Attestation service. Therefore, the goal of this research project is to find a new way to break the protection of the data sent in a TLS session, with certificate pinning and SafetyNet Attestation service implemented, in an Android environment. The SafetyNet Attestation service is an anti-abuse system that focusses on the integrity of the Android application and the Android device which it is running on. As part of the integrity checks on the Android device, it can detect whether a device is rooted.
    [Show full text]
  • Applied Crypto Hardening
    Applied Crypto HarDENING WOLFGANG BrEyha, David Durvaux, TOBIAS Dussa, L. AarON Kaplan, Florian Mendel, Christian Mock, Manuel Koschuch, Adi Kriegisch, Ulrich Pöschl, Ramin Sabet, BerG San, Ralf Schlatterbeck, Thomas Schreck, AleXANDER Würstlein, AarON Zauner, Pepi Zawodsky (University OF Vienna, CERT.be, KIT-CERT, CERT.at, A-SIT/IAIK, CORetec.at, FH Campus Wien, VRVis, MilCERT Austria, A-Trust, Runtux.com, Friedrich-AleXANDER University Erlangen-NurEMBERg, azet.org, maclemon.at) NoVEMBER 10, 2016 Do NOT TALK UNENCRYPTED Applied Crypto HarDENING PAGE 2 OF 111 AcknoWLEDGEMENTS WE WOULD LIKE TO EXPRESS OUR THANKS TO THE FOLLOWING REVIEWERS AND PEOPLE WHO HAVE GENEROUSLY OffERED THEIR TIME AND INTEREST (in ALPHABETICAL ORder): BrOwn, Scott Pacher, Christoph Brulebois, Cyril Palfrader, Peter Dirksen-Thedens, Mathis Pape, TOBIAS (layout) DulaunoY, AleXANDRE Petukhova, Anna (Logo) Gühring Philipp Pichler, Patrick Grigg, IAN Riebesel, Nicolas Haslinger, Gunnar Roeckx, Kurt Huebl, AxEL Roesen, Jens Kovacic, Daniel Rublik, Martin Lenzhofer, Stefan Schüpany, Mathias Lorünser, Thomas Schwarz, René («DigNative») Maass, Max Seidl, Eva (PDF layout) Mehlmauer, Christian VAN Horenbeeck, Maarten Millauer, TOBIAS Wagner, Sebastian («sebix») Mirbach, AndrEAS Zangerl, AleXANDER O’Brien, Hugh The REVIEWERS DID REVIEW PARTS OF THE DOCUMENT IN THEIR AREA OF Expertise; ALL REMAINING ERRORS IN THIS DOCUMENT ARE THE SOLE RESPONSIBILITY OF THE PRIMARY authors. Applied Crypto HarDENING PAGE 3 OF 111 AbstrACT “Unfortunately, THE COMPUTER SECURITY AND CRYPTOLOGY COMMUNITIES HAVE DRIFTED APART OVER THE LAST 25 years. Security PEOPLE DON’T ALWAYS UNDERSTAND THE AVAILABLE CRYPTO tools, AND CRYPTO PEOPLE DON’T ALWAYS UNDERSTAND THE Real-world PRoblems.” — Ross Anderson IN [And08] This GUIDE AROSE OUT OF THE NEED FOR SYSTEM ADMINISTRATORS TO HAVE AN updated, solid, WELL Re- SEARCHED AND thought-thrOUGH GUIDE FOR CONfiGURING SSL, PGP, SSH AND OTHER CRYPTOGRAPHIC TOOLS IN THE post-SnoWDEN age.
    [Show full text]