DOCSLIB.ORG

Software Vulnerability Disclosure in Europe

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Software Vulnerability Disclosure in Europe Software Vulnerability This report puts forward the analysis and recommendations for the design and implementation of a forward-looking policy on software vulnerability disclosure (SVD) in Europe. It is the result of extensive deliberations among the members Disclosure in Europe of a Task Force formed by CEPS in September 2017, including industry experts, representatives of EU and international institutions, academics, civil society Technology, Policies and Legal Challenges organisations and practitioners. Drawing on current best practices throughout Europe, the US and Japan, the Report of a CEPS Task Force Task Force explored ways to formulate practical guidelines for governments and businesses to harmonise the process of handling SVD throughout Europe. These discussions led to policy recommendations addressed to member states and the EU institutions for the development of an effective policy framework for introducing coordinated vulnerability disclosure (CVD) and government disclosure decision processes (GDDP) in Europe. Software Vulnerability Disclosure in Europe Software Vulnerability Chair: Marietje Schaake Rapporteurs: Lorenzo Pupillo Afonso Ferreira CEPS Gianluca V arisco Software Vulnerability Disclosure in Europe Software Vulnerability Disclosure in Europe Technology, Policies and Legal Challenges Report of a CEPS Task Force June 2018 Chair: Marietje Schaake Rapporteurs: Lorenzo Pupillo Afonso Ferreira Gianluca Varisco Centre for European Policy Studies (CEPS) Brussels CEPS is an independent think tank based in Brussels, whose mission is to produce sound analytical research leading to constructive solutions to the challenges facing Europe today. The views presented in this report do not necessarily represent the opinions of all the participants of the Task Force, nor do they explicitly represent the view of any individual participant (unless explicitly mentioned in this report). The views expressed in this report are those of the authors writing in a personal capacity and do not necessarily reflect those of CEPS or any other institution with which they are associated. ISBN 978-94-6138-687-8 © Copyright 2018, CEPS All rights reserved. No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form or by any means – electronic, mechanical, photocopying, recording or otherwise – without the prior permission of the Centre for European Policy Studies. CEPS Place du Congrès 1, B-1000 Brussels Tel: 32 (0) 2 229.39.11 e-mail: [email protected] internet: www.ceps.eu Table of Contents Foreword ....................................................................................................................... i Preface .......................................................................................................................... iii Executive Summary .................................................................................................... v CVD Policy ........................................................................................................... v Policy Recommendations from the Task Force .............................................. vi Part I. Coordinated Vulnerability Disclosure in Europe 1. Introduction...........................................................................................................1 1.1. Background ...................................................................................................1 1.2. Some definitions ...........................................................................................4 1.3. What is vulnerability disclosure? ...............................................................4 1.4. Coordinated vulnerability disclosure ........................................................5 1.5. Actors in CVD ...............................................................................................6 1.6. Phases of CVD ..............................................................................................7 1.6.1. Bug bounty programs .......................................................................9 1.7. Special cases of CVD ....................................................................................9 1.7.1. Multiparty CVD .................................................................................9 1.7.2. Forever day vulnerabilities.............................................................11 1.8. Future issues in CVD .................................................................................11 3. State of play in CVD, by country .....................................................................13 3.1. CVD within member states .......................................................................13 3.2. Case studies of CVD in selected EU member states ..............................23 3.2.1. The Netherlands ..............................................................................23 3.2.2. Latvia .................................................................................................30 3.3. Case studies of CVD outside the EU .......................................................34 3.3.1. United States.....................................................................................34 3.3.2. Japan ..................................................................................................39 4. Legal challenges from software vulnerability disclosure in the EU ...........41 4.1. Circumstances in which disclosure of software security vulnerability is advantageous ..........................................................................................41 4.2. Legal challenges in relation to software vulnerability disclosure and the relevant legislative framework ..........................................................42 4.3. Criminal law ................................................................................................42 4.4. Data protection law ....................................................................................46 4.5. Industrial property .....................................................................................47 4.5.1. Copyright ..........................................................................................47 4.5.2. Trade secrets .....................................................................................48 4.5.3. Patents ...............................................................................................48 4.5.4. Trademarks .......................................................................................48 4.6. Export control regulation ..........................................................................48 4.7. Conclusion ...................................................................................................49 5. Policy implications .............................................................................................50 6. Recommendations for implementing CVD in Europe ..................................53 6.1. Introduction.................................................................................................53 6.1.1. Opportunity cost ..............................................................................53 6.1.2. What can be done at EU level?.......................................................53 6.2. EU legislation ..............................................................................................54 6.2.1. Amending Directive 2013/40/EU on attacks against information systems to support CVD. ..........................................54 6.2.2. Protection of security researchers ..................................................54 6.2.3. Incentives for security researchers ................................................54 6.2.4. Directive on security of network information systems ..............54 6.2.5. General Data Protection Regulation .............................................55 6.2.6. Cybersecurity Act ............................................................................56 6.2.7. Software vulnerabilities in durable goods ..................................57 6.3. National legislation ....................................................................................57 6.4. National non-legislative activities ............................................................57 6.5. Framework Programme for Research and Innovation ..........................58 Part II. Government Disclosure Decision Processes...........................................61 7. Government Disclosure Decision Processes ...................................................63 7.1. GDDP in Europe .........................................................................................64 7.2. The US experience with GDDP ................................................................64 7.3. Recommendations for establishing GDDP in the EU ............................73 Part III. Conclusions and Recommendations 8. Conclusions: It is time to act .............................................................................79 8.1. CVD policies................................................................................................79 8.2. Recommendations for the implementation of CVD in Europe ............81 8.2.1. EU legislation ...................................................................................81 8.2.2. National legislation .........................................................................82 8.2.3. EU research funding ........................................................................83 8.3. Recommendations
Load more

Recommended publications
  • 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]
  • Architect's Guide for Securing Network Equipment
    JANUARY 2018 ARCHITECT’S GUIDE FOR SECURING NETWORK EQUIPMENT Trusted Computing Group 3855 SW 153rd Drive Tel (503) 619-0562 Fax (503) 644-6708 [email protected] www.trustedcomputinggroup.org Architect’s Guide for Security Network Equipment Copyright© 2018 Trusted Computing Group | All Rights Reserved ARCHITECT’S GUIDE FOR SECURING NETWORK EQUIPMENT As part of the critical infrastructure of an enterprise, network equipment (Side Bar 1) is subject to the same types of attacks and threats as PCs, servers and the network itself. THESE THREATS INCLUDE: UNAUTHORIZED DEVICES UNAUTHORIZED CODE FIRMWARE IMPLANTS THAT 1 THAT CAN GAIN ACCESS 2 THAT CAN INTERFERE 3 CAN RENDER ATTACKS TO NETWORKED DATA WITH SAFE OPERATION INVISIBLE AND UNREMOVABLE Preserving the integrity and security of network equipment is essential to maintaining customer privacy and network reliability. Trusted Computing solutions can be used to provide these requirements. This Architect’s Guide makes the case for addressing network security and provides some initial guidance from ongoing efforts in this area. AWARENESS PRIOR TO ACTION Experts in providing trust to all aspects of an It is important to distinguish network security enterprise have found that many designers are not provided by items such as firewalls, VPNs, MPLS concerned about protecting the low-level, embedded domains, access lists, intrusion detection, network portions of their infrastructure. For example, those access controls, Radius, DMZs and a host of other people who are interested specifically in network functions that prevent inappropriate access to security are extremely concerned about almost all networked resources, from Secure Network aspects that involve anti-viruses and software but Equipment.
    [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]
  • Privacy and Security
    Privacy and Security Sekar Kulandaivel, Jennifer Xiao - April 21, 2020 Understanding Contention-Based Channels and Using Them for Agenda Defense Spectre Attacks: Exploiting Speculative Execution Understanding Contention-Based Channels and Using Them for Defense (HPCA ‘15) Distrustful tenants living within a neutral cloud provider ● Shared hardware can be exploited to leak information ○ e.g. CPU usage vs. operation can expose secret key ● Two bodies of solutions: ○ HW-based: state-of-the-art is either limited in scope or requires impractical architecture changes ○ SW-based: HomeAlone forgoes shared hardware and permits only friendly co-residency, but still vulnerable to an intelligent attacker Threat model of a co-resident attacker ● Distrustful tenants violate confidentiality or compromise availability ● Goal: infer info about victim VM via microarchitectural structures e.g. cache and memory controllers ● Side-channel: victim inadvertently (oops!) leaks data inferred by attacker ● Covert channel: privileged malicious process on victim deliberately leaks data to attacker Known side-channels to transmit a ‘0’ or a ‘1’ (alt. exec.) ● Alternative execution attacks ○ Timing-driven: measure time to access memory portion ○ Access-driven: measure time to access specific cache misses Known side-channels to transmit a ‘0’ or a ‘1’ (parallel exec.) ● Parallel execution attacks ○ No time sharing required ○ E.g. Receiver monitors latency of memory fetch, sender either issues more instructions or idles Formal model of covert channels ● Detection failure (undetectable flow) = same rate of false positives and false negatives for both legitimate and covert traffic ● Network vs. microarchitectural channels: ○ Network receivers read silently ○ Microarch. receivers read destructively (overwrites when reading) ● Main insight: network channels are provably undetectable whereas microarch.
    [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]
  • 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]
  • Full Disclosure
    FULL DISCLOSURE David C Frier Atos RSS - 2017 FULL DISCLOSURE: Topics ● About your speaker ● What is -- and is NOT -- a “hacker”? ● Cybercriminals and Researchers ● What is -- and is NOT -- a “zero-day”? ● Disclosure, Responsible and Otherwise ● Bug Bounties About Your Speaker ● David C Frier, CISSP, CISM, CRISC, CCSK ● Client Security Manager for Atos, caring for Xerox’s infrastructure ...but I speak only for myself, not for Atos! ● I’ve been doing Information Security for a dozen years ● I’ve been doing IT of one sort or another for Jack Benny’s age ● Avid player of poker and Ingress, enthusiastic rider of a Trek. ● $FIRST.$LAST@{gmail.com | atos.net} ● Not on LinkedIn ...but feel free to check my profile at Google+ if the Ambien has stopped working. What’s a Hacker? ● Hacker n. (from Wikitionary) 1. (computing) One who is expert at programming and solving problems with a computer. 2. (computing) One who uses a computer to gain unauthorized access to data, or to carry out malicious attacks. 3. (computing) A computer security professional. ● The top discussion item on that wiki entry simply says, Unfortunately, the original sense of this word is no longer primary, and as much as I would like to reclaim the original sense, that battle is long since lost. If you use hacker outside the hacker community, expect to be misunderstood. ● TL;DR - Hacker ≠ Criminal Cybercriminals? ● Cybercriminals may or may not be hackers. ○ They may hire technical capability, and not exercise it themselves ○ They may be only script-kiddies ○ They might not even be criminals: They may be state-sponsored, and thus their actions are legal, under their nation’s laws ● Meanwhile, hacking is: ○ A set of problem-solving approaches ○ A toolbox of techniques ○ Morally neutral ● IFF the goal of the hacking is a crime, then a hacker also happens to be a cybercriminal.
    [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]