DOCSLIB.ORG

Mission Accomplished? HTTPS Security After Diginotar

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Mission Accomplished? HTTPS Security After Diginotar Mission Accomplished? HTTPS Security after DigiNotar Johanna Amann∗ Oliver Gasser∗ Quirin Scheitle∗ ICSI / Corelight / LBNL Technical University of Munich Technical University of Munich [email protected] [email protected] [email protected] Lexi Brent Georg Carle Ralph Holz The University of Sydney Technical University of Munich The University of Sydney [email protected] [email protected] [email protected] ABSTRACT ACM Reference Format: Driven by CA compromises and the risk of man-in-the-middle Johanna Amann, Oliver Gasser, Quirin Scheitle, Lexi Brent, Georg attacks, new security features have been added to TLS, Carle, and Ralph Holz. 2017. Mission Accomplished? HTTPS Security after DigiNotar. In Proceedings of IMC ’17, London, HTTPS, and the web PKI over the past five years. These United Kingdom, November 1–3, 2017, 16 pages. include Certificate Transparency (CT), for making the CA https://doi.org/10.1145/3131365.3131401 system auditable; HSTS and HPKP headers, to harden the HTTPS posture of a domain; the DNS-based extensions CAA and TLSA, for control over certificate issuance and pinning; 1 INTRODUCTION and SCSV, for protocol downgrade protection. The compromise of the DigiNotar CA in 2011 [57] was a This paper presents the first large scale investigation of decisive event in the history of WWW security: for the first these improvements to the HTTPS ecosystem, explicitly ac- time, a CA was removed from browser root stores, because counting for their combined usage. In addition to collecting of poor infrastructure control and the subsequent issuance passive measurements at the Internet uplinks of large Uni- of forged certificates51 [ ]. In the same year, several studies versity networks on three continents, we perform the largest documented the poor state of the TLS/X.509 ecosystem in domain-based active Internet scan to date, covering 193M general [8, 24, 39]. domains. Furthermore, we track the long-term deployment Since then, a number of improvements and additions have history of new TLS security features by leveraging passive been proposed to strengthen the X.509 PKI. They include observations dating back to 2012. Certificate Transparency (CT)44 [ ], which establishes a set of We find that while deployment of new security features has publicly verifiable append-only certificate logs; HTTP Strict picked up in general, only SCSV (49M domains) and CT (7M Transport Security (HSTS) [36], which instructs browsers domains) have gained enough momentum to improve the over- to only connect through HTTPS; HPKP, which allows cer- all security of HTTPS. Features with higher complexity, such tificate pinning through HTTP headers25 [ ]; SCSV, which as HPKP, are deployed scarcely and often incorrectly. Our em- protects against protocol downgrading attacks [50]; DANE- pirical findings are placed in the context of risk, deployment TLSA, which enables HTTPS certificate pinning using the effort, and benefit of these new technologies, and actionable DNS [37]; and finally CAA [33], which allows control of cer- steps for improvement are proposed. We cross-correlate use tificate issuance through the DNS. of features and find some techniques with significant correla- In this paper, we investigate the prevalence of these tech- tion in deployment. We support reproducible research and nologies, audit the correctness of their deployment, and ex- publicly release data and code. amine the combined role they play in post-DigiNotar web security. Our contributions are as follows: We combine active CCS CONCEPTS and passive measurements to investigate the improvements • Security and privacy → Network security; to TLS and the web PKI. Our measurements include hitherto the largest active scans of the TLS/X.509 ecosystem. Rather ∗Joint first authorship. than performing an active scan of the IP address space, our scans target a list of 193M domain names. This provides a more complete view, as many HTTPS servers implement Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that the Server Name Indication (SNI) extension to serve dif- copies are not made or distributed for profit or commercial advantage ferent certificates and use different TLS configurations per and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than the au- domain [71]. This domain-based approach also reduces bias thor(s) must be honored. Abstracting with credit is permitted. To copy caused by the common presence of embedded devices that otherwise, or republish, to post on servers or to redistribute to lists, happen to run web servers [16]. Our active scans originate requires prior specific permission and/or a fee. Request permissions from [email protected]. from two vantage points on opposite ends of the globe, using IMC ’17, November 1–3, 2017, London, United Kingdom both IPv4 and IPv6. We also perform passive measurements © 2017 Copyright held by the owner/author(s). Publication rights in North America, Europe, and Australia. To the best of our licensed to Association for Computing Machinery. ACM ISBN 978-1-4503-5118-8/17/11. $15.00 knowledge, this is the first time that such a geographically https://doi.org/10.1145/3131365.3131401 diverse passive TLS observation has been conducted. Our IMC ’17, November 1–3, 2017, London, United Kingdom Amann, Gasser, Scheitle, Brent, Carle, Holz data analysis uses a novel process in which active and passive that prevents browsers from validating it; it cannot be used data share the same analysis pipeline. in place of a real certificate. The log server signs the precer- We investigate each of the above technologies in depth, tificate and returns SCTs for it. These are embedded intoan particularly focusing on Certificate Transparency and new X.509 extension of the final certificate. Browsers verify the TLS and HTTPS extensions. Importantly, we also investigate embedded SCTs by reconstructing the precertificate. how these technologies are used in combination, and which At the time of writing, Google Chrome is the only popu- protection level is thereby achieved. We paint an accurate pic- lar browser that verifies SCTs. It supports all transmission ture to which degree these technologies are correctly deployed methods, and requires valid SCTs for Extended Validation and which mistakes are commonly made. We contextualize (EV) certificates, removing the EV trust indicator otherwise. our empirical findings and explore the correlation between HTTP-based extensions: HTTP Strict Transport Security complexity, benefit, and risk of each technology. Additionally, (HSTS) [36] and HTTP Public Key Pinning (HPKP) [25] are we examine the proliferation of different TLS versions by HTTP extensions that aim to increase the security of the drawing on a massive data set of global connection-level TLS HTTPS ecosystem by setting HTTP header values. HSTS information collected since 2012. instructs the client to only access a domain via HTTPS. We strive to support open science and release our active HPKP enables the server to pin specific public keys toa scan dataset to the community. Along with parsed results, domain to mitigate man-in-the-middle attacks. Browsers must we make packet-level data captures available, allowing for abort a connection if none of the pins match the certificate precise reproduction and new uses. We also feed software chain used by the domain. Both HSTS and HPKP directives changes back to the community, and publish newly created are shipped with web browsers in so-called preloading lists. tools under a permissive open-source license. Data and code SCSV Downgrade Prevention: RFC 7507 [50] defines a Sig- can be found at https://mediatum.ub.tum.de/1377982. naling Cipher Suite Value (SCSV) that is used to prevent The remainder of this paper is organized as follows. Sec- downgrade attacks in which an attacker prevents connections tion2 covers the technical background. Section3 details with strong TLS versions in order to exploit weaknesses in the related work. Section4 describes our methodology. Sec- older TLS versions. Clients commonly fall back to older TLS tions5,6,7, and8 present our results for CT, HSTS and versions if a connection attempt with a newer TLS version HPKP, SCSV, and the DNS-based extensions CAA and is unsuccessful. In this fallback case, the client appends the DANE-TLSA, respectively. Section9 shows the evolution SCSV pseudo-cipher value to its list of supported ciphers. of TLS version use over the last five years. We discuss our When receiving this SCSV, the server must abort the connec- findings and relate them to risk, cost, and benefit of thenew tion if it supports a higher protocol version. One motivation technologies in Section 10, and summarize them in Section 11. for SCSV was the infamous POODLE attack [49]. DNS-based Extensions: Both Certification Authority Autho- 2 BACKGROUND rization (CAA) [33] and TLS Authentication (TLSA) [37] are DNS record types introduced to aid certificate issuance and This section describes the TLS, HTTP, and DNS based verification, respectively. CAA indicates which CAs may HTTPS security extensions we investigate. For a general issue certificates for a domain. It also supports reporting web PKI introduction, we refer the reader to [18, 39]. in cases where a CA is requested to issue a certificate for CT: Certificate Transparency (CT) [44] aims to make un- a domain, but may not do so because of the CAA record. noticed attacks on the PKI near-impossible through public CAA was accepted by the CA/Browser forum as a mandatory disclosure of certificate issuance. Users or CAs submit certifi- step during certificate issuance [12] and became effective on cate chains for inclusion in one or more semi-trusted public September 8, 2017. logs, run by independent parties. Each log stores entries in an In contrast to all other methods, the CAA record is only append-only Merkle Hash Tree.
Load more

Recommended publications
  • Alcatel-Lucent Security Advisory Sa0xx
    Alcatel-Lucent Security Advisory No. SA0053 Ed. 04 Information about Poodle vulnerability Summary POODLE stands for Padding Oracle On Downgraded Legacy Encryption. The POODLE has been reported in October 14th 2014 allowing a man-in-the-middle attacker to decrypt ciphertext via a padding oracle side-channel attack. The severity is not considered as the same for Heartbleed and/or bash shellshock vulnerabilities. The official risk is currently rated Medium. The classification levels are: Very High, High, Medium, and Low. The SSLv3 protocol is only impacted while TLSv1.0 and TLSv1.2 are not. This vulnerability is identified CVE- 2014-3566. Alcatel-Lucent Enterprise voice products using protocol SSLv3 are concerned by this security alert. Openssl versions concerned by the vulnerability: OpenSSL 1.0.1 through 1.0.1i (inclusive) OpenSSL 1.0.0 through 1.0.0n (inclusive) OpenSSL 0.9.8 through 0.9.8zb (inclusive) The Alcatel-Lucent Enterprise Security Team is currently investigating implications of this security flaw and working on a corrective measure, for OpenTouch 2.1.1 planned in Q4 2015, to prevent using SSLv3 that must be considered as vulnerable. This note is for informational purpose about the padding-oracle attack identified as “POODLE”. References CVE-2014-3566 http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-3566 Advisory severity CVSS Base score : 4.3 (MEDIUM) - AV:N/AC:M/Au:N/C:P/I:N/A:N https://www.openssl.org/news/secadv_20141015.txt https://www.openssl.org/~bodo/ssl-poodle.pdf Description of the vulnerabilities Information about Poodle vulnerability (CVE-2014-3566).
    [Show full text]
  • Systematization of Vulnerability Discovery Knowledge: Review
    Systematization of Vulnerability Discovery Knowledge Review Protocol Nuthan Munaiah and Andrew Meneely Department of Software Engineering Rochester Institute of Technology Rochester, NY 14623 {nm6061,axmvse}@rit.edu February 12, 2019 1 Introduction As more aspects of our daily lives depend on technology, the software that supports this technology must be secure. We, as users, almost subconsciously assume the software we use to always be available to serve our requests while preserving the confidentiality and integrity of our information. Unfortunately, incidents involving catastrophic software vulnerabilities such as Heartbleed (in OpenSSL), Stagefright (in Android), and EternalBlue (in Windows) have made abundantly clear that software, like other engineered creations, is prone to mistakes. Over the years, Software Engineering, as a discipline, has recognized the potential for engineers to make mistakes and has incorporated processes to prevent such mistakes from becoming exploitable vulnerabilities. Developers leverage a plethora of processes, techniques, and tools such as threat modeling, static and dynamic analyses, unit/integration/fuzz/penetration testing, and code reviews to engineer secure software. These practices, while effective at identifying vulnerabilities in software, are limited in their ability to describe the engineering failures that may have led to the introduction of vulnerabilities. Fortunately, as researchers propose empirically-validated metrics to characterize historical vulnerabilities, the factors that may have led to the introduction of vulnerabilities emerge. Developers must be made aware of these factors to help them proactively consider security implications of the code that they contribute. In other words, we want developers to think like an attacker (i.e. inculcate an attacker mindset) to proactively discover vulnerabilities.
    [Show full text]
  • RSA-512 Certificates Abused in the Wild
    RSA-512 Certificates abused in the wild During recent weeks we have observed several interesting publications which have a direct relation to an investigation we worked on recently. On one hand there was a Certificate Authority being revoked by Mozilla, Microsoft and Google (Chrome), on the other hand there was the disclosure of a malware attack by Mikko Hypponen (FSecure) using a government issued certificate signed by the same Certificate Authority. That case however is not self-contained and a whole range of malicious software had been signed with valid certificates. The malicious software involved was used in targeted attacks focused on governments, political organizations and the defense industry. The big question is of course, what happened, and how did the attackers obtain access to these certificates? We will explain here in detail how the attackers have used known techniques to bypass the Microsoft Windows code signing security model. Recently Mikko Hypponen wrote a blog on the F-Secure weblog (http://www.f-secure.com/weblog/archives/00002269.html) detailing the discovery of a certificate used to sign in the wild malware. Specifically this malware was embedded in a PDF exploit and shipped in August 2011. Initially Mikko also believed the certificate was stolen, as that is very common in these days, with a large amount of malware families having support, or optional support, for stealing certificates from the infected system. Apparently someone Mikko spoke to mentioned something along the lines that it had been stolen a long time ago. During the GovCert.nl symposium Mikko mentioned the certificate again, but now he mentioned that according to the people involved with investigating the case in Malaysia it likely wasn't stolen.
    [Show full text]
  • Internet Security Threat Report VOLUME 21, APRIL 2016 TABLE of CONTENTS 2016 Internet Security Threat Report 2
    Internet Security Threat Report VOLUME 21, APRIL 2016 TABLE OF CONTENTS 2016 Internet Security Threat Report 2 CONTENTS 4 Introduction 21 Tech Support Scams Go Nuclear, 39 Infographic: A New Zero-Day Vulnerability Spreading Ransomware Discovered Every Week in 2015 5 Executive Summary 22 Malvertising 39 Infographic: A New Zero-Day Vulnerability Discovered Every Week in 2015 8 BIG NUMBERS 23 Cybersecurity Challenges For Website Owners 40 Spear Phishing 10 MOBILE DEVICES & THE 23 Put Your Money Where Your Mouse Is 43 Active Attack Groups in 2015 INTERNET OF THINGS 23 Websites Are Still Vulnerable to Attacks 44 Infographic: Attackers Target Both Large and Small Businesses 10 Smartphones Leading to Malware and Data Breaches and Mobile Devices 23 Moving to Stronger Authentication 45 Profiting from High-Level Corporate Attacks and the Butterfly Effect 10 One Phone Per Person 24 Accelerating to Always-On Encryption 45 Cybersecurity, Cybersabotage, and Coping 11 Cross-Over Threats 24 Reinforced Reassurance with Black Swan Events 11 Android Attacks Become More Stealthy 25 Websites Need to Become Harder to 46 Cybersabotage and 12 How Malicious Video Messages Could Attack the Threat of “Hybrid Warfare” Lead to Stagefright and Stagefright 2.0 25 SSL/TLS and The 46 Small Business and the Dirty Linen Attack Industry’s Response 13 Android Users under Fire with Phishing 47 Industrial Control Systems and Ransomware 25 The Evolution of Encryption Vulnerable to Attacks 13 Apple iOS Users Now More at Risk than 25 Strength in Numbers 47 Obscurity is No Defense
    [Show full text]
  • The Dark Reality of Open Source Spotlight Report
    SPOTLIGHT The Dark Reality of Open Source Through the Lens of Threat and Vulnerability Management RiskSense Spotlight Report • May 2020 Executive Summary Open sourCe software (OSS) has quiCkly transformed both And while Heartbleed and the Apache Struts how modern applications are built and the underlying code vulnerabilities are the household names of open source they rely on. Access to high-quality and powerful open vulnerabilities, they are far from the only examples. Open source software projects has allowed developers to quickly source software is increasingly being targeted by integrate new capabilities into their applications without cryptominers, ransomware, and leveraged in DDoS having to reinvent the wheel. As a result, it is now estimated attacks. Unfortunately, OSS vulnerabilities are often a that between 80% and 90% of the code in most modern blind spot for many enterprises, who may not always be applications is made up of open source components. aware of all the open source projects and dependencies Likewise, many of the very tools that have enabled the that are used in their applications. growth of DevOps and CI/CD such as Jenkins, Kubernetes, and Docker are themselves open source projects. With this in mind, we have focused this version of the RiskSense Spotlight report on vulnerabilities in some of OSS also allows organizations to reduce their software today’s most popular open source software, including costs, and is often key to digital transformation efforts more than 50 OSS projects and over 2,600 vulnerabilities. and the transition of services to the cloud. It is no We then used this dataset to provide a risk-based surprise then that a 2020 report from Red Hat found that analysis of open source software to reveal the following: 95% of organizations view open source software as strategically important to their business.
    [Show full text]
  • Combat Top Security Vulnerabilities: HPE Tippingpoint Intrusion
    Business white paper Combat top security vulnerabilities HPE TippingPoint intrusion prevention system Business white paper Page 2 The year 2014 marked a new pinnacle for hackers. Vulnerabilities were uncovered in some of the most widely deployed software in the world—some of it in systems actually intended to make you more secure. HPE TippingPoint next-generation intrusion prevention system (IPS) and next-generation firewall (NGFW) customers rely on us to keep their networks safe. And when it comes to cyber threats, every second matters. So how did HPE TippingPoint do? This brief highlights the top security vulnerabilities of 2014—the ones that sent corporate security executives scrambling to protect their businesses. And it describes how HPE TippingPoint responded to keep our customers safe. Heartbleed—HPE TippingPoint intrusion prevention system stops blood flow early Any vulnerability is concerning, but when a vulnerability is discovered in software designed to assure security, it leaves businesses exposed and vulnerable. That was the case with the Heartbleed vulnerability disclosed by the OpenSSL project on April 7, 2014. They found the vulnerability in versions of OpenSSL—the open-source cryptographic library widely used to encrypt Internet traffic. Heartbleed grew from a coding error that allowed remote attackers to read information from process memory by sending heartbeat packets that trigger a buffer over-read. As a demonstration of the vulnerability, the OpenSSL Project created a sample exploit that successfully stole private cryptography keys, user names and passwords, instant messages, emails, and business-critical documents and communications. We responded within hours to protect TippingPoint customers. On April 8, we released a custom filter package to defend against the vulnerability.
    [Show full text]
  • IBM X-Force Threat Intelligence Quarterly, 1Q 2015
    IBM Security Systems March 2015 IBM X-Force Threat Intelligence Quarterly, 1Q 2015 Explore the latest security trends—from “designer vulns” to mutations in malware— based on 2014 year-end data and ongoing research 2 IBM X-Force Threat Intelligence Quarterly 1Q 2015 Contents Executive overview 2 Executive overview When we look back in history to review and understand the past year, you can be assured it will be remembered as a year of 4 Roundup of security incidents in 2014 significant change. 11 Citadel, the financial malware that continues to adapt In early January 2014, companies large and small scrambled to Are mobile application developers for Android putting their 14 better understand and analyze a major retail breach that left users at risk? them asking whether or not their own security measures would 17 Shaking the foundation: Vulnerability disclosures in 2014 survive the next storm. Before spring was barely in motion, we had our first taste of the “designer vuln”—a critical 21 About X-Force vulnerability that not only proved lethal for targeted attacks, 22 Contributors but also had a cleverly branded logo, website and call-name (or handle) that would forever identify the disclosure. 22 For more information 23 Footnotes These designer vulns appeared within long-held foundational frameworks used by the majority of websites, and they continued throughout 2014, garnering catchy name after catchy name—Heartbleed, Shellshock, POODLE, and into 2015, Ghost and FREAK. This in and of itself raises the question of what it takes for a vulnerability to merit a marketing push, PR and logo design, while the other thousands discovered throughout the year do not.
    [Show full text]
  • TLS Attacks & DNS Security
    IAIK TLS Attacks & DNS Security Information Security 2019 Johannes Feichtner [email protected] IAIK Outline TCP / IP Model ● Browser Issues Application SSLStrip Transport MITM Attack revisited Network Link layer ● PKI Attacks (Ethernet, WLAN, LTE…) Weaknesses HTTP TLS / SSL FLAME FTP DNS Telnet SSH ● Implementation Attacks ... ● Protocol Attacks ● DNS Security IAIK Review: TLS Services All applications running TLS are provided with three essential services Authentication HTTPS FTPS Verify identity of client and server SMTPS ... Data Integrity Detect message tampering and forgery, TLS e.g. malicious Man-in-the-middle TCP IP Encryption Ensure privacy of exchanged communication Note: Technically, not all services are required to be used Can raise risk for security issues! IAIK Review: TLS Handshake RFC 5246 = Establish parameters for cryptographically secure data channel Full handshake Client Server scenario! Optional: ClientHello 1 Only with ServerHello Client TLS! Certificate 2 ServerKeyExchange Certificate CertificateRequest ClientKeyExchange ServerHelloDone CertificateVerify 3 ChangeCipherSpec Finished ChangeCipherSpec 4 Finished Application Data Application Data IAIK Review: Certificates Source: http://goo.gl/4qYsPz ● Certificate Authority (CA) = Third party, trusted by both the subject (owner) of the certificate and the party (site) relying upon the certificate ● Browsers ship with set of > 130 trust stores (root CAs) IAIK Browser Issues Overview Focus: Relationship between TLS and HTTP Problem? ● Attacker wants to access encrypted data ● Browsers also have to deal with legacy websites Enforcing max. security level would „break“ connectivity to many sites Attack Vectors ● SSLStrip ● MITM Attack …and somehow related: Cookie Stealing due to absent „Secure“ flag… IAIK Review: ARP Poisoning How? Attacker a) Join WLAN, ● Sniff data start ARP Poisoning ● Manipulate data b) Create own AP ● Attack HTTPS connections E.g.
    [Show full text]
  • Web and Mobile Security
    Cyber Security Body of Knowledge: Web and Mobile Security Sergio Maffeis Imperial College London bristol.ac.uk © Crown Copyright, The National Cyber Security Centre 2021. This information is licensed under the Open Government Licence v3.0. To view this licence, visit http://www.nationalarchives.gov.uk/doc/open- government-licence/. When you use this information under the Open Government Licence, you should include the following attribution: CyBOK Web & Mobile Security Knowledge Area Issue 1.0 © Crown Copyright, The National Cyber Security Centre 2021, licensed under the Open Government Licence http://www.nationalarchives.gov.uk/doc/open- government-licence/. The CyBOK project would like to understand how the CyBOK is being used and its uptake. The project would like organisations using, or intending to use, CyBOK for the purposes of education, training, course development, professional development etc. to contact it at [email protected] to let the project know how they are using CyBOK. bristol.ac.uk Web & Mobile Security KA • This webinar covers and complements selected topics from the “Web & Mobile Security Knowledge Area - Issue 1.0” document [WMS-KA for short] • “The purpose of this Knowledge Area is to provide an overview of security mechanisms, attacks and defences in modern web and mobile ecosystems.” • We assume basic knowledge of the web and mobile platforms – The WMS-KA also covers some of the basic concepts assumed here Web and Mobile Security 3 Scope • The focus of WMS-KA is on the intersection of mobile and web security, as a result of recent appification and webification trends. – The KA does not cover specific mobile-only aspects including mobile networks, mobile malware, side channels.
    [Show full text]
  • SSL/TLS Interception Proxies and Transitive Trust Jeff Jarmoc Dell Secureworks Counter Threat Unit℠ Threat Intelligence
    SSL/TLS Interception Proxies and Transitive Trust Jeff Jarmoc Dell SecureWorks Counter Threat Unit℠ Threat Intelligence Presented at Black Hat Europe – March 14, 2012. Introduction Secure Sockets Layer (SSL) [1] and its successor Transport Layer Security (TLS) [2] have become key components of the modern Internet. The privacy, integrity, and authenticity [3] [4] provided by these protocols are critical to allowing sensitive communications to occur. Without these systems, e- commerce, online banking, and business-to-business exchange of information would likely be far less frequent. Threat actors have also recognized the benefits of transport security, and they are increasingly turning to SSL to hide their activities. Advanced Persistent Threat (APT) attackers [5], botnets [6], and even commodity web attacks can leverage SSL encryption to evade detection. To counter these tactics, organizations are increasingly deploying security controls that intercept end- to-end encrypted channels. Web proxies, data loss prevention (DLP) systems, specialized threat detection solutions, and network intrusion prevention systems (NIPS) offer functionality to intercept, inspect, and filter encrypted traffic. Similar functionality is present in lawful intercept systems and solutions enabling the broad surveillance of encrypted communications by governments. Broadly classified as “SSL/TLS interception proxies,” these solutions act as a “man in the middle,” violating the end-to-end security promises of SSL. This type of interception comes at a cost. Intercepting SSL-encrypted connections sacrifices a degree of privacy and integrity for the benefit of content inspection, often at the risk of authenticity and endpoint validation. Implementers and designers of SSL interception proxies should consider these risks and understand how their systems operate in unusual circumstances.
    [Show full text]
  • Certificate Transparency: New Part of PKI Infrastructure
    Certificate transparency: New part of PKI infrastructure A presentation by Dmitry Belyavsky, TCI ENOG 7 Moscow, May 26-27, 2014 About PKI *) *) PKI (public-key infrastructure) is a set of hardware, software, people, policies, and procedures needed to create, manage, distribute, use, store, and revoke digital certificates Check the server certificate The server certificate signed correctly by any of them? Many trusted CAs NO YES Everything seems to We warn the user be ok! DigiNotar case OCSP requests for the fake *.google.com certificate Source: FOX-IT, Interim Report, http://cryptome.org/0005/diginotar-insec.pdf PKI: extra trust Independent Trusted PKI source certificate DANE (RFC 6698) Certificate pinning Limited browsers support Mozilla Certificate Patrol, Chrome cache for Google certificates Certificate transparency (RFC 6962) Inspired by Google (Support in Chrome appeared) One of the authors - Ben Laurie (OpenSSL Founder) CA support – Comodo Certificate Transparency: how it works • Log accepts cert => SCT Client • Is SCT present and signed correctly? Client • Is SCT present and signed correctly? Auditor • Does log server behave correctly? Monitor • Any suspicious certs? Certificate Transparency: how it works Source: http://www.certificate-transparency.org Certificate Transparency how it works Source: http://www.certificate-transparency.org Certificate Transparency current state Google Chrome Support (33+) http://www.certificate-transparency.org/certificate-transparency-in-chrome Google Cert EV plan http://www.certificate-transparency.org/ev-ct-plan Certificate Transparency current state Open source code 2 pilot logs Certificate Transparency: protect from what? SAVE from MITM attack ü Warning from browser ü Site owner can watch logs for certs Do NOT SAVE from HEARTBLEED! Certificate transparency and Russian GOST crypto Russian GOST does not save from the MITM attack Algorithm SHA-256 >>> GOSTR34.11-2012 Key >>> GOST R 34.10-2012 Q&A Questions? Drop ‘em at: [email protected] .
    [Show full text]
  • Automating Patching of Vulnerable Open-Source Software Versions in Application Binaries
    Automating Patching of Vulnerable Open-Source Software Versions in Application Binaries Ruian Duan:, Ashish Bijlani:, Yang Ji:, Omar Alrawi:, Yiyuan Xiong˚, Moses Ike:, Brendan Saltaformaggio,: and Wenke Lee: fruian, ashish.bijlani, yang.ji, alrawi, [email protected], [email protected] [email protected], [email protected] : Georgia Institute of Technology, ˚ Peking University Abstract—Mobile application developers rely heavily on open- while ensuring backward compatibility, and test for unin- source software (OSS) to offload common functionalities such tended side-effects. For the Android platform, Google has as the implementation of protocols and media format playback. initiated the App Security Improvement Program (ASIP) [21] Over the past years, several vulnerabilities have been found in to notify developers of vulnerable third-party libraries in popular open-source libraries like OpenSSL and FFmpeg. Mobile use. Unfortunately, many developers, as OSSPolice [15] and applications that include such libraries inherit these flaws, which LibScout [4] show, do not update or patch their application, make them vulnerable. Fortunately, the open-source community is responsive and patches are made available within days. However, which leaves end-users exposed. Android developers mainly mobile application developers are often left unaware of these use Java and C/C++ [1] libraries. While Derr et al. [14] flaws. The App Security Improvement Program (ASIP) isa show that vulnerable Java libraries can be fixed by library- commendable effort by Google to notify application developers level update, their C/C++ counterparts, which contain many of these flaws, but recent work has shown that many developers more documented security bugs in the National Vulnerability do not act on this information.
    [Show full text]