DOCSLIB.ORG

SSL/TLS: the Ugly Truth Examining the flaws in SSL/TLS Protocols, and the Use of Certificate Authorities

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
SSL/TLS: the Ugly Truth Examining the flaws in SSL/TLS Protocols, and the Use of Certificate Authorities SSL/TLS: The Ugly Truth Examining the flaws in SSL/TLS protocols, and the use of certificate authorities. Adrian Hayter CNS Hut 3 Team [email protected] Contents • Introduction to SSL/TLS • Cryptography Crash Course • Certificates • Weaknesses in SSL/TLS • The Certificate Authority System • Solutions & Recommendations • Questions Adrian Hayter Page: 2/26 What is SSL/TLS? Secure Sockets Layer (versions 2.0, 3.0) Transport Layer Security (versions 1.0, 1.1, 1.2) Cryptographic protocols that allow secure communication over a network. Uses: • Authentication of participants. • Key exchange. • Encryption of data. • Data integrity. Adrian Hayter Page: 3/26 What is SSL/TLS? Secure Sockets Layer (versions 2.0, 3.0) Transport Layer Security (versions 1.0, 1.1, 1.2) Cryptographic protocols that allow secure communication over a network. Uses: • Authentication of participants. • Key exchange. • Encryption of data. • Data integrity. Adrian Hayter Page: 3/26 Cryptography Crash Course If you already know about cryptography, feel free to ignore the next few slides! Adrian Hayter Page: 4/26 Cryptography Crash Course: Symmetric Cryptography Alice Bob Alice and Bob both have a copy of a secret key. Alice encrypts a message using the secret key and sends it to Bob. Bob decrypts the message using the secret key. Bob encrypts a message using the secret key and sends it to Alice. Alice decrypts the message using the secret key. Adrian Hayter Page: 5/26 Cryptography Crash Course: Symmetric Cryptography • Encryption / Decryption is simple and easy for a computer to do. Secret keys are also easy to generate. • Requires participants to have set up the shared secret key beforehand. Problems: How do participants set up a shared secret key? What if the participants don’t know each other? Adrian Hayter Page: 6/26 Cryptography Crash Course: Symmetric Cryptography • Encryption / Decryption is simple and easy for a computer to do. Secret keys are also easy to generate. • Requires participants to have set up the shared secret key beforehand. Problems: How do participants set up a shared secret key? What if the participants don’t know each other? Adrian Hayter Page: 6/26 Cryptography Crash Course: Asymmetric Cryptography Alice Bob Alice and Bob generate their own private and public key pairs. Alice and Bob share their public keys with each other. Alice encrypts a message with Bob's public key and sends it to Bob. Bob decrypts the message with his private key. Bob encrypts a message with Alice's public key and sends it to Alice. Alice decrypts the message with her private key. Adrian Hayter Page: 7/26 Cryptography Crash Course: Asymmetric Cryptography • Asymmetric Cryptography is also known as Public-key Cryptography. • Public / Private keys are mathematically linked. Knowledge of one of the keys does not compromise the other. • Does not require the participants to have set up any shared secrets beforehand, or even know each other. Problem: Both the key pair generation and the encryption / decryption processes are complex and take much longer for computers to do than with symmetric cryptography. Adrian Hayter Page: 8/26 Cryptography Crash Course: Asymmetric Cryptography • Asymmetric Cryptography is also known as Public-key Cryptography. • Public / Private keys are mathematically linked. Knowledge of one of the keys does not compromise the other. • Does not require the participants to have set up any shared secrets beforehand, or even know each other. Problem: Both the key pair generation and the encryption / decryption processes are complex and take much longer for computers to do than with symmetric cryptography. Adrian Hayter Page: 8/26 A Solution We can combine symmetric and asymmetric cryptography. 1. Alice & Bob generate public/private keys beforehand. 2. When Alice wants to send a message to Bob, she asks Bob to send her his public key. 3. Bob sends Alice his public key. 4. Alice creates a symmetric key, encrypts it using Bob’s public key, and sends the encrypted key to Bob. 5. Bob decrypts the symmetric key using his private key and stores it. 6. Alice and Bob can now encrypt/decrypt messages using the shared symmetric key. Adrian Hayter Page: 9/26 A Solution We can combine symmetric and asymmetric cryptography. 1. Alice & Bob generate public/private keys beforehand. 2. When Alice wants to send a message to Bob, she asks Bob to send her his public key. 3. Bob sends Alice his public key. 4. Alice creates a symmetric key, encrypts it using Bob’s public key, and sends the encrypted key to Bob. 5. Bob decrypts the symmetric key using his private key and stores it. 6. Alice and Bob can now encrypt/decrypt messages using the shared symmetric key. Adrian Hayter Page: 9/26 A Solution We can combine symmetric and asymmetric cryptography. 1. Alice & Bob generate public/private keys beforehand. 2. When Alice wants to send a message to Bob, she asks Bob to send her his public key. 3. Bob sends Alice his public key. 4. Alice creates a symmetric key, encrypts it using Bob’s public key, and sends the encrypted key to Bob. 5. Bob decrypts the symmetric key using his private key and stores it. 6. Alice and Bob can now encrypt/decrypt messages using the shared symmetric key. Adrian Hayter Page: 9/26 A Solution We can combine symmetric and asymmetric cryptography. 1. Alice & Bob generate public/private keys beforehand. 2. When Alice wants to send a message to Bob, she asks Bob to send her his public key. 3. Bob sends Alice his public key. 4. Alice creates a symmetric key, encrypts it using Bob’s public key, and sends the encrypted key to Bob. 5. Bob decrypts the symmetric key using his private key and stores it. 6. Alice and Bob can now encrypt/decrypt messages using the shared symmetric key. Adrian Hayter Page: 9/26 A Solution We can combine symmetric and asymmetric cryptography. 1. Alice & Bob generate public/private keys beforehand. 2. When Alice wants to send a message to Bob, she asks Bob to send her his public key. 3. Bob sends Alice his public key. 4. Alice creates a symmetric key, encrypts it using Bob’s public key, and sends the encrypted key to Bob. 5. Bob decrypts the symmetric key using his private key and stores it. 6. Alice and Bob can now encrypt/decrypt messages using the shared symmetric key. Adrian Hayter Page: 9/26 A Solution We can combine symmetric and asymmetric cryptography. 1. Alice & Bob generate public/private keys beforehand. 2. When Alice wants to send a message to Bob, she asks Bob to send her his public key. 3. Bob sends Alice his public key. 4. Alice creates a symmetric key, encrypts it using Bob’s public key, and sends the encrypted key to Bob. 5. Bob decrypts the symmetric key using his private key and stores it. 6. Alice and Bob can now encrypt/decrypt messages using the shared symmetric key. Adrian Hayter Page: 9/26 “Man in the Middle Attack” Alice Mallory Bob "Hey Bob, it's Alice. Can I have your public key?" "Hey Bob, it's Alice. Can I have your public key?" Bob sends his public key. Mallory sends his public key. How do we solve this problem? A problem with our solution! Alice and Bob don’t ever verify that they are actually talking to each other! Adrian Hayter Page: 10/26 Alice Mallory Bob "Hey Bob, it's Alice. Can I have your public key?" "Hey Bob, it's Alice. Can I have your public key?" Bob sends his public key. Mallory sends his public key. A problem with our solution! Alice and Bob don’t ever verify that they are actually talking to each other! “Man in the Middle Attack” How do we solve this problem? Adrian Hayter Page: 10/26 Certificates A digital certificate binds a public key to an identity using a digital signature. The digital signature almost always comes from a trusted third party. If the signature is trusted, the certificate is valid, and the public key is verified to belong to the specified identity. In the SSL/TLS system, X.509 certificates are signed by Certificate Authorities (e.g. VeriSign, Comodo, Entrust, PositiveSSL). More on these later... Adrian Hayter Page: 11/26 Certificate Fields Subject: The identity the public key belongs to (e.g. Bob, www.example.com). Issuer: The identity that signed and issued the certificate (e.g. VeriSign). Signature: The signature of the issuer. Not Before / Not After: Dates when the certificate is valid. Public Key: The subject’s public key. Version, Serial Number, Signature Algorithm, Public Key Algorithm Adrian Hayter Page: 12/26 (Highly) Simplified SSL/TLS Handshake Client Server Client requests SSL/TLS connection. Sends some random bytes to the server. Server sends certificate. Sends some random bytes to the client. Client verifies certificate, generates pre-master secret, encrypts the secret with the server's public key, and sends it to the server. The server decrypts the pre-master secret and uses it to generate a shared master secret, which is then used to generate session keys. The client generates the same master secret and session keys. The client and server encrypt and exchange data using the session keys. Adrian Hayter Page: 13/26 SSL/TLS: Common Security Weaknesses • Use of outdated protocols: SSLv2. • Use of weak ciphers: symmetric encryption (<128 bits), asymmetric encryption (<2048 bits). • Expired / invalid certificates. • Self-signed certificates. • Renegotiation. Web based: • Login over HTTPS, everything else over HTTP (sslstrip exploits this). Adrian Hayter Page: 14/26 Attacks against SSL/TLS BEAST (Browser Exploit Against SSL/TLS) – Developed in 2011. Affects all versions of SSL/TLS except TLS 1.1 and 1.2.
Load more

Recommended publications
  • Using Frankencerts for Automated Adversarial Testing of Certificate
    Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations Chad Brubaker ∗ y Suman Janay Baishakhi Rayz Sarfraz Khurshidy Vitaly Shmatikovy ∗Google yThe University of Texas at Austin zUniversity of California, Davis Abstract—Modern network security rests on the Secure Sock- many open-source implementations of SSL/TLS are available ets Layer (SSL) and Transport Layer Security (TLS) protocols. for developers who need to incorporate SSL/TLS into their Distributed systems, mobile and desktop applications, embedded software: OpenSSL, NSS, GnuTLS, CyaSSL, PolarSSL, Ma- devices, and all of secure Web rely on SSL/TLS for protection trixSSL, cryptlib, and several others. Several Web browsers against network attacks. This protection critically depends on include their own, proprietary implementations. whether SSL/TLS clients correctly validate X.509 certificates presented by servers during the SSL/TLS handshake protocol. In this paper, we focus on server authentication, which We design, implement, and apply the first methodology for is the only protection against man-in-the-middle and other large-scale testing of certificate validation logic in SSL/TLS server impersonation attacks, and thus essential for HTTPS implementations. Our first ingredient is “frankencerts,” synthetic and virtually any other application of SSL/TLS. Server authen- certificates that are randomly mutated from parts of real cer- tication in SSL/TLS depends entirely on a single step in the tificates and thus include unusual combinations of extensions handshake protocol. As part of its “Server Hello” message, and constraints. Our second ingredient is differential testing: if the server presents an X.509 certificate with its public key.
    [Show full text]
  • Installing Fake Root Keys in a PC
    View metadata, citation and similar papers at core.ac.uk brought to you by CORE provided by Royal Holloway - Pure Installing Fake Root Keys in a PC Adil Alsaid and Chris J. Mitchell Information Security Group Royal Holloway, University of London Egham, Surrey TW20 0EX fA.Alsaid, [email protected] Abstract. If a malicious party can insert a self-issued CA public key into the list of root public keys stored in a PC, then this party could potentially do considerable harm to that PC. In this paper, we present a way to achieve such an attack for the Internet Explorer web browser root key store, which avoids attracting the user's attention. A realisation of this attack is also described. Finally, countermeasures that can be deployed to prevent such an attack are outlined. 1 Introduction As is widely known [10], most web browsers (e.g. Microsoft Internet Explorer or Netscape) have a repository of root public keys designed for use in verify- ing digitally signed public key certi¯cates. These public keys are bundled with distributions of the web browser, and are used to verify certi¯cates for applet providers [13]. Speci¯cally, web-sites may download applets to a user PC without the PC user knowing it. Depending on the security settings selected by the PC user, these applets may be executed with or without further checks. Typically, the browser will only execute the applet if the following conditions are satis¯ed. 1. The applet must be digitally signed, and the signature must verify correctly. 2.
    [Show full text]
  • Analysis of SSL Certificate Reissues and Revocations in the Wake
    Analysis of SSL Certificate Reissues and Revocations in the Wake of Heartbleed Liang Zhang David Choffnes Dave Levin Tudor Dumitra¸s Northeastern University Northeastern University University of Maryland University of Maryland [email protected] [email protected] [email protected] [email protected] Alan Mislove Aaron Schulman Christo Wilson Northeastern University Stanford University Northeastern University [email protected] [email protected] [email protected] ABSTRACT Categories and Subject Descriptors Central to the secure operation of a public key infrastruc- C.2.2 [Computer-Communication Networks]: Net- ture (PKI) is the ability to revoke certificates. While much work Protocols; C.2.3 [Computer-Communication Net- of users' security rests on this process taking place quickly, works]: Network Operations; E.3 [Data Encryption]: in practice, revocation typically requires a human to decide Public Key Cryptosystems, Standards to reissue a new certificate and revoke the old one. Thus, having a proper understanding of how often systems admin- istrators reissue and revoke certificates is crucial to under- Keywords standing the integrity of a PKI. Unfortunately, this is typi- Heartbleed; SSL; TLS; HTTPS; X.509; Certificates; Reissue; cally difficult to measure: while it is relatively easy to deter- Revocation; Extended validation mine when a certificate is revoked, it is difficult to determine whether and when an administrator should have revoked. In this paper, we use a recent widespread security vul- 1. INTRODUCTION nerability as a natural experiment. Publicly announced in Secure Sockets Layer (SSL) and Transport Layer Secu- April 2014, the Heartbleed OpenSSL bug, potentially (and rity (TLS)1 are the de-facto standards for securing Internet undetectably) revealed servers' private keys.
    [Show full text]
  • Ten Strategies of a World-Class Cybersecurity Operations Center Conveys MITRE’S Expertise on Accumulated Expertise on Enterprise-Grade Computer Network Defense
    Bleed rule--remove from file Bleed rule--remove from file MITRE’s accumulated Ten Strategies of a World-Class Cybersecurity Operations Center conveys MITRE’s expertise on accumulated expertise on enterprise-grade computer network defense. It covers ten key qualities enterprise- grade of leading Cybersecurity Operations Centers (CSOCs), ranging from their structure and organization, computer MITRE network to processes that best enable effective and efficient operations, to approaches that extract maximum defense Ten Strategies of a World-Class value from CSOC technology investments. This book offers perspective and context for key decision Cybersecurity Operations Center points in structuring a CSOC and shows how to: • Find the right size and structure for the CSOC team Cybersecurity Operations Center a World-Class of Strategies Ten The MITRE Corporation is • Achieve effective placement within a larger organization that a not-for-profit organization enables CSOC operations that operates federally funded • Attract, retain, and grow the right staff and skills research and development • Prepare the CSOC team, technologies, and processes for agile, centers (FFRDCs). FFRDCs threat-based response are unique organizations that • Architect for large-scale data collection and analysis with a assist the U.S. government with limited budget scientific research and analysis, • Prioritize sensor placement and data feed choices across development and acquisition, enteprise systems, enclaves, networks, and perimeters and systems engineering and integration. We’re proud to have If you manage, work in, or are standing up a CSOC, this book is for you. served the public interest for It is also available on MITRE’s website, www.mitre.org. more than 50 years.
    [Show full text]
  • Analysis of SSL Certificate Reissues And
    Analysis of SSL Certificate Reissues and Revocations in the Wake of Heartbleed Liang Zhang David Choffnes Dave Levin Tudor Dumitra¸s Northeastern University Northeastern University University of Maryland University of Maryland [email protected] [email protected] [email protected] [email protected] Alan Mislove Aaron Schulman Christo Wilson Northeastern University Stanford University Northeastern University [email protected] [email protected] [email protected] ABSTRACT Categories and Subject Descriptors Central to the secure operation of a public key infrastruc- C.2.2 [Computer-Communication Networks]: Net- ture (PKI) is the ability to revoke certificates. While much work Protocols; C.2.3 [Computer-Communication Net- of users' security rests on this process taking place quickly, works]: Network Operations; E.3 [Data Encryption]: in practice, revocation typically requires a human to decide Public Key Cryptosystems, Standards to reissue a new certificate and revoke the old one. Thus, having a proper understanding of how often systems admin- istrators reissue and revoke certificates is crucial to under- Keywords standing the integrity of a PKI. Unfortunately, this is typi- Heartbleed; SSL; TLS; HTTPS; X.509; Certificates; Reissue; cally difficult to measure: while it is relatively easy to deter- Revocation; Extended validation mine when a certificate is revoked, it is difficult to determine whether and when an administrator should have revoked. In this paper, we use a recent widespread security vul- 1. INTRODUCTION nerability as a natural experiment. Publicly announced in Secure Sockets Layer (SSL) and Transport Layer Secu- April 2014, the Heartbleed OpenSSL bug, potentially (and rity (TLS)1 are the de-facto standards for securing Internet undetectably) revealed servers' private keys.
    [Show full text]
  • A Systematic Study of Cache Side Channels Across AES Implementations
    A Systematic Study of Cache Side Channels across AES Implementations Heiko Mantel1, Alexandra Weber1, and Boris K¨opf 2 1 Computer Science Department, TU Darmstadt, Darmstadt, Germany [email protected], [email protected] 2 IMDEA Software Institute, Madrid, Spain [email protected] Abstract While the AES algorithm is regarded as secure, many imple- mentations of AES are prone to cache side-channel attacks. The lookup tables traditionally used in AES implementations for storing precom- puted results provide speedup for encryption and decryption. How such lookup tables are used is known to affect the vulnerability to side chan- nels, but the concrete effects in actual AES implementations are not yet sufficiently well understood. In this article, we analyze and compare multiple off-the-shelf AES implementations wrt. their vulnerability to cache side-channel attacks. By applying quantitative program analysis techniques in a systematic fashion, we shed light on the influence of im- plementation techniques for AES on cache-side-channel leakage bounds. 1 Introduction The Advanced Encryption Standard (AES) is a widely used symmetric cipher that is approved by the U.S. National Security Agency for security-critical ap- plications [8]. While traditional attacks against AES are considered infeasible as of today, software implementations of AES are known to be highly suscepti- ble to cache side-channel attacks [5, 15, 18, 19, 32]. While such side channels can be avoided by bitsliced implementations [6,23], lookup-table-based implementa- tions, which aim at better performance, are often vulnerable and wide spread. To understand the vulnerability to cache side-channel attacks, recall that the 128bit version of AES relies on 10 rounds of transformations.
    [Show full text]
  • Certificate Transparency Using Blockchain
    Certicate Transparency Using Blockchain D S V Madala1, Mahabir Prasad Jhanwar1, and Anupam Chattopadhyay2 1Department of Computer Science. Ashoka University, India 2School of Computer Science and Engineering. NTU, Singapore Abstract The security of web communication via the SSL/TLS protocols relies on safe distribu- tions of public keys associated with web domains in the form of X:509 certicates. Certicate authorities (CAs) are trusted third parties that issue these certicates. However, the CA ecosystem is fragile and prone to compromises. Starting with Google's Certicate Trans- parency project, a number of research works have recently looked at adding transparency for better CA accountability, eectively through public logs of all certicates issued by certica- tion authorities, to augment the current X:509 certicate validation process into SSL/TLS. In this paper, leveraging recent progress in blockchain technology, we propose a novel system, called CTB, that makes it impossible for a CA to issue a certicate for a domain without obtaining consent from the domain owner. We further make progress to equip CTB with certicate revocation mechanism. We implement CTB using IBM's Hyperledger Fabric blockchain platform. CTB's smart contract, written in Go, is provided for complete reference. 1 Introduction The overwhelming adoption of SSL/TLS (Secure Socket Layer/Transport Layer Security Proto- cols) [4, 33] for most HTTP trac has transformed the Internet into a communication platform with strong measures of condentiality and integrity. It is one
    [Show full text]
  • Public Key Distribution (And Certifications)
    Lecture 12 Public Key Distribution (and Certifications) (Chapter 15 in KPS) 1 A Typical KDC-based Key Distribution Scenario KDC = Key Distribution Center KDC EK[X] = Encryption of X with key K (1) Request|B|N1 (2) E [K |Request|N |E (K ,A)] Ka s 1 Kb s (3) E [K ,A] Kb s A (4) E [A,N ] Ks 2 B Notes: (5) E [f(N )] Ks 2 • Msg2 is tied to Msg1 • Msg2 is fresh/new • Msg3 is possibly old * • Msg1 is possibly old (KDC doesn’t authenticate Alice) • Bob authenticates Alice • Bob authenticates KDC 2 • Alice DOES NOT authenticate Bob Public Key Distribution • General Schemes: • Public announcement (e.g., in a newsgroup or email message) • Can be forged • Publicly available directory • Can be tampered with • Public-key certificates (PKCs) issued by trusted off-line Certification Authorities (CAs) 3 Certification Authorities • Certification Authority (CA): binds public key to a specific entity • Each entity (user, host, etc.) registers its public key with CA. • Bob provides “proof of identity” to CA. • CA creates certificate binding Bob to this public key. • Certificate containing Bob’s public key digitally signed by CA: CA says: “this is Bob’s public key” Bob’s digital PK public signature B key PK B certificate for Bob’s CA Bob’s private SK public key, signed by identifying key CA CA information 4 Certification Authority • When Alice wants to get Bob’s public key: • Get Bob’s certificate (from Bob or elsewhere) • Using CA’s public key verify the signature on Bob’s certificate • Check for expiration • Check for revocation (we’ll talk about this later) • Extract Bob’s public key Bob’s PK B digital Public signature Key PK B CA Public PK Key CA 5 A Certificate Contains • Serial number (unique to issuer) • Info about certificate owner, including algorithm and key value itself (not shown) • info about certificate issuer • valid dates • digital signature by issuer 6 Reflection Attack and a Fix • Original Protocol 1.
    [Show full text]
  • The BEAST Wins Again: Why TLS Keeps Failing to Protect HTTP Antoine Delignat-Lavaud, Inria Paris Joint Work with K
    The BEAST Wins Again: Why TLS Keeps Failing to Protect HTTP Antoine Delignat-Lavaud, Inria Paris Joint work with K. Bhargavan, C. Fournet, A. Pionti, P.-Y. Strub INTRODUCTION Introduction Cookie Cutter Virtual Host Confusion Crossing Origin Boundaries Shared Session Cache Shared Reverse Proxies SPDY Connection Pooling Triple Handshake Conclusion Why do we need TLS? 1. Authentication – Must be talking to the right guy 2. Integrity – Our messages cannot be tampered 3. Confidentiality – Messages are only legible to participants 4. Privacy? – Can’t tell who we are and what we talk about Why do we need TLS? 1. Authentication – Must be talking to the right guy Active Attacks 2. Integrity (MitM) – Our messages cannot be tampered 3. Confidentiality – Messages are only legible to participants Passive Attacks 4. Privacy? (Wiretapping) – Can’t tell who we are and what we talk about What websites expect of TLS • Web attacker – Controls malicious websites – User visits honest and malicious sites in parallel – Web/MitB attacks: CSRF, XSS, Redirection… • Network attacker – Captures (passive) and tampers (active) packets What websites expect of TLS • Web attacker – Controls malicious websites – User visits honest and malicious sites in parallel – Web/MitB attacks: CSRF, XSS, Redirection… • Network attacker Strictly stronger – Captures (passive) and tampers (active) packets What websites expect of TLS If a website W served over HTTP is secure against a Web attacker, then serving W over HTTPS makes it secure against a network attacker. What websites expect of TLS If a website W served over HTTP is secure against a Web attacker, then serving W over HTTPS makes it secure against a network attacker.
    [Show full text]
  • Searching for Trust
    SEARCHing for Trust Scott Rea1, TBA GOV2, TBA EDU3 1DigiCert Inc, Lindon, UT U.S.A., [email protected] 2Gov Agency, TBA, Australia, [email protected] 3University or Corporation, TBA, Australia, [email protected] ABSTRACT The security of the X.509 “oligarchy” Public Key Infrastructure for browsers and SSL web servers is under scrutiny in response to Certification Authority (CA) compromises which resulted in the circulation of fraudulent certificates. These rogue certificates can and have been used to execute Man-in-the-Middle attacks and gain access to users’ sensitive information. In wake of these events, there has been a call for change to the extent of either securing the current system or altogether replacing it with an alternative design. This panel will review the results of the research paper to be published that will explore the following proposals which have been put forth to replace or improve the CA system with the goal of aiding in the prevention and detection of MITM attacks and improving the trust infrastructure: Convergence, Perspectives, Mutually Endorsed Certification Authority Infrastructure (MECAI), DNS-Based Authentication of Named Entities (DANE), DNS Certification Authority Authorization (CAA) Resource Records, Public Key Pinning, Sovereign Keys, and Certificate Transparency. In the paper, a new metric is described that ranks each proposal according to a set of well-identified criteria and gives readers an idea of the costs and benefits of implementing the proposed system and the potential strengths and weaknesses of the design. The results of the research and the corresponding impacts for eResearchers and Government collaborators will be discussed by the panel.
    [Show full text]
  • Certificate Transparency Description
    Certificate Transparency Description Certificate Transparency is an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. (q.v. IETF RFC 6962) The objectives are described as: Make it very difficult for a CA to issue a TLS certificate for a domain without the certificate being visible to the owner of that domain. Provide an open auditing and monitoring system that lets any domain owner or CA determine whether certificates have been mistakenly or maliciously issued. Protect users from being duped by certificates that were mistakenly or maliciously issued. (q.v. https://www.certificate-transparency.org/what-is-ct) Note that end user TLS clients are not responsible for validating CT logs, all they need to do is enforce a requirement that certificates must have extensions that show that they were issued under these procedures by validating a Signed Certificate Timestamp (SCT) data object presented with the TLS server certificate. Monitors and Auditors have the primary responsibility of detecting anomalous certificates that were never submitted to the logs. According to wikipedia, the implementation status of the standard is as follows: Google launched its first certificate transparency log in March 2013.
    [Show full text]
  • Whither Deprecating TCP-MD5? a Light Dose of Reality Vs
    Deprecating MD5 for LDP draft-nslag-mpls-deprecate-md5- 00.txt The IETF MPLS and PALS WG Chairs Our Problem • Control plane protocols are often carried over simple transport layers such as UDP or TCP. • Control planes are good targets for attack and their disruption or subversion can have serious operational consequences. • TCP RST attacks against BGP routers were the original motivation for RFC 2385, TCP-MD5. • LDP runs over TCP. • It currently uses TCP MD5 for authentication, which is no longer considered secure (see RFC 5925) • This is frequently pointed out to us when our documents go to the IESG for publication. Small Survey among operators and vendors - I • The survey was totally un-scientific, and just a small number of vendors and operators were asked. Questions could be better formulated. • Operators were asked. • If TCP-AO were available in products, would you use it? • Are you planning to deploy it? • Vendors were asked. • Do you have TCP-AO? • We will consider making a bigger and more scientific survey to send out to “everybody”. Small Survey among operators and vendors - II • Operators answered: • No plan to deploy TCP-AO as long as vendors support their MD-5 implementations. • Very few authenticated LDP sessions. • There is a cost to deploy TCP-AO. • Vendors answered: • No we don’t have TCP-AO in our products. • One vendor said that it will be available later this year. • We will not implement it until we hear from the operators that they need it. What we need • A security suit that: • Is more secure than MD5 when used over the long-lived sessions that support routing.
    [Show full text]