DOCSLIB.ORG

SSL/TLS Attacks Network Security 2018/2019 Pedro Brandão

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
SSL/TLS Attacks Network Security 2018/2019 Pedro Brandão Seg. Redes [d cc] SSL/TLS attacks Network Security 2018/2019 Pedro Brandão 2 [d cc] BEAST May 2011 Browser Exploit Against SSL/TLS SegRedes 18/19 - TLS Attacks - pbrandao Firewalls 1 Seg. Redes BEAST 3 • Browser Exploit Against SSL/TLS, “Here Come The ⊕ Ninjas”, Thai Duong and Juliano Rizzo, May 13, 2011 o Client side attack • SSL v3.0 and TLS 1.0 • Attack on CBC mode with chained IVs o Mandatory on SSL and TLS o Chosen plaintext attack • Known since 2004 (G.V. Bard) o Thought un-exploitable (no practical exploit) • History of the development by Thai Duong ] SegRedes 18/19 - TLS Attacks - pbrandao [d cc BEAST 4 • Requirements: o Ability to eavesdrop https requests (MiTM) o Ability to modify https requests being made . Agent loaded from evil.com that sends requests to victim.com . Same origin: victim.com may allow JavaScript from evil.com (WebSocket); Java may be used, Flash, Silverlight, etc. • Enables decryption of bytes in the requests o http cookies From [⊕ Ninjas] ] SegRedes 18/19 - TLS Attacks - pbrandao [d cc Firewalls 2 Seg. Redes BEAST - Solutions 5 • Don’t use SSL v3 or TLS 1.0 • Mitigate prediction of IVs o 1/1-n split. • Server o Use RC4 encryption (not CBC) . but there’s an attack for that ] SegRedes 18/19 - TLS Attacks - pbrandao [d cc 6 [d cc] POODLE September 2014 Padding Oracle On Downgraded Legacy Encryption SegRedes 18/19 - TLS Attacks - pbrandao Firewalls 3 Seg. Redes POODLE 7 • Padding Oracle On Downgraded Legacy Encryption • Google Security team: Bodo Möller, Thai Duong and Krzysztof Kotowicz • Affects even if server and client support recent versions of TLS o Need to downgrade to SSLv3 ] SegRedes 18/19 - TLS Attacks - pbrandao [d cc POODLE 8 • Use: o RC4 bias attack . if the same data is sent several times using RC4, info will leak o POODLE focus on block cipher in CBC mode • Attacker: o Interfere with TLS version negotiation to get to SSL v3.0; o Deploy js on browser to send HTTPS requests and intercept SSL records sent by browser o Send padding data with the partial contents of a previous block (cookie) o If record accepted, 1 byte can be recovered, continue o Expected requests are 256 per byte to decrypt ] SegRedes 18/19 - TLS Attacks - pbrandao [d cc Firewalls 4 Seg. Redes POODLE Solutions 9 • Disable support for SSLv3.0 o Browsers and/or servers o “Unlike with the BEAST [BEAST] and Lucky 13 [Lucky13] attacks, there is no reasonable workaround. “ [POODLEBites] • Server support for RFC7507: TLS Fallback Signaling Cipher Suite Value (SCSV) for Preventing Protocol Downgrade Attacks o Client when downgrading sets 0x56, 0x00 (TLS_FALLBACK_SCSV) in the supported suites . Naturally it is not a selectable suite o This indicates server that client is downgrading o If server supports higher version than the one requested generate error. ] SegRedes 18/19 - TLS Attacks - pbrandao [d cc 10 [d cc] FREAK March 2015 Factoring RSA Export Keys SegRedes 18/19 - TLS Attacks - pbrandao Firewalls 5 Seg. Redes FREAK 11 • March 3, 2015, Karthikeyan Bhargavan at INRIA in Paris and the miTLS team • RSA_EXPORT cipher suites o Vulnerable (on purpose) to attacks • Need MiTM to trick browser to downgrade o Server does not sign chosen cipher suite • Some TLS Clients allowed the RSA_EXPORT cipher suites although not announcing them • Found using formal analysis tools ] SegRedes 18/19 - TLS Attacks - pbrandao [d cc FREAK – Export Crypto 12 • “introduced under the pressure of US governments agencies to ensure that they would be able to decrypt all foreign encrypted communication, while stronger algorithms were banned from export (as they were classified as weapons of war).“ o Do the current tendencies for crypto communication requested to companies ring a bell? • “export RSA moduli must be less than 512 bits long; hence, they can be factored in less than 12 hours for $100 on Amazon EC2” From [SMACK] ] SegRedes 18/19 - TLS Attacks - pbrandao [d cc Firewalls 6 Seg. Redes FREAK – vulnerable 13 From [SMACK] • Vulnerable TLS client libraries included o OpenSSL (CVE-2015-0204): versions before 1.0.1k are vulnerable. Upgrade. o BoringSSL: versions before Nov 10, 2014 are vulnerable. Upgrade. o SecureTransport (CVE-2015-1067, CVE-2015-2235): versions before iOS 8.2, AppleTV 7.1, and OS X Security Update 2015-002 are vulnerable. Update your OS. o SChannel (CVE-2015-1637): before KB3046049 is vulnerable. See the security bulletin. Update your OS. o LibReSSL: versions before 2.1.2 are vulnerable. Upgrade. o Mono: versions before 3.12.1 are vulnerable. Upgrade. o IBM JSSE: is vulnerable. A fix is being tested. • Web browsers that use the above TLS libraries are vulnerable, including: o Chrome: versions before 41 on various platforms are vulnerable. Update. o Internet Explorer: on OS versions before March 9 are vulnerable. Update your OS. o Safari: on OS versions before March 9 are vulnerable. Update your OS. o Opera: versions before 28 are vulnerable. Update. o Android Browser: is vulnerable. Switch to Chrome 41. o Blackberry Browser: is vulnerable. See the advisory. Wait for a patch. o Cisco: products using OpenSSL are vulnerable. See the advisory. ] SegRedes 18/19 - TLS Attacks - pbrandao [d cc FREAK solutions 14 • Server: o Disable TLS export suites • Browser: o Update • Update system libraries for SSL: o OpenSSL, Microsoft Schannel and Apple SecureTransport “Encryption backdoors will always turn around and bite you in the ass. They are never worth it.” -- Matt Green (in [FREAK]) ] SegRedes 18/19 - TLS Attacks - pbrandao [d cc Firewalls 7 Seg. Redes 15 [d cc] LogJam May 2015 SegRedes 18/19 - TLS Attacks - pbrandao LogJam 16 o NRS, Inria Nancy-Grand Est, Inria Paris-Rocquencourt, Microsoft Research, Johns Hopkins University, University of Michigan, and the University of Pennsylvania: David Adrian, Karthikeyan Bhargavan, Zakir Durumeric, Pierrick Gaudry, Matthew Green, J. Alex Halderman, Nadia Heninger, Drew Springall, Emmanuel Thomé, Luke Valenta, Benjamin VanderSloot, Eric Wustrow, Santiago Zanella-Beguelin, and Paul Zimmermann. • Attacks Diffie-Hellman using known and widely deployed prime numbers • Pre-compute 푙표푔 for given prime (they used 2 bundled in Apache and openssl) o Accelerate log calculation for connection key discovery ] SegRedes 18/19 - TLS Attacks - pbrandao [d cc Firewalls 8 Seg. Redes LogJam 17 • Needs o downgrade to RSA_Export as FREAK o TLS False Start (client sends data before receiving final response from server) • Attacks the TLS protocol (not the implementation) • From [LogJam] o “512-bit prime used for TLS downgrade connections to 80% of TLS servers supporting DHE_EXPORT.” o “academic team can break a 768-bit prime and a nation-state can break a 1024-bit prime.” ] SegRedes 18/19 - TLS Attacks - pbrandao [d cc LogJam 18 From miTLS LogJam ] SegRedes 18/19 - TLS Attacks - pbrandao [d cc Firewalls 9 Seg. Redes LogJam – Solutions 19 • Server o Disable export ciphers o Generate longer (2048) DH key o [LogJam] has instructions • Browser o Upgrade • Libraries o Upgrade ] SegRedes 18/19 - TLS Attacks - pbrandao [d cc • BERserk: vulnerability in the Mozilla NSS crypto library. Error in parsing ASN.1 encoded in BER. Allows RSA sig 20 Others forging (2006) • CRIME, use of compression in the protocol allows for recovery of cookies. Presentation (2012) • BREACH, builds on CRIME attacking HTTP responses. (2013) • Lucky-13: timing attack on the result of padding in TLS (desc on GnuTLS)(2013) • SLOTH, Attacks TLS 1.2 RSA-MD5 signatures • Heart Bleed (XKCD explanation): use special crafted heart beat packets to get the server to send its memory content (2014) o CloudBleed (Cloudflare reverse proxy sends more data than it should), GoogleZero • DROWN, uses a secondary connection to a server using the same cert but with SSLv2. It allows to decrypt blocks of the non-SSLv2 connection. Paper (2016) ] SegRedes 18/19 - TLS Attacks - pbrandao [d cc Firewalls 10 Seg. Redes 21 [d cc] Certificates for everyone SegRedes 18/19 - TLS Attacks - pbrandao Let’s encrypt 22 • Effort by EFF • Quick and one command install and configuration of working signed certificate • Uses ACME protocol (being prepared as an IETF RFC) o Automated Certificate Management Environment ] SegRedes 18/19 - TLS Attacks - pbrandao [d cc Firewalls 11 Seg. Redes • Challenges by the let’s encrypt server 23 Let’s Encrypt oDNS control oHost control Process overview oSigning nonce Image from Let’s Encrypt, Technology ] SegRedes 18/19 - TLS Attacks - pbrandao [d cc Let’s Encrypt 24 • CertBot from EFF $ sudo dnf install python-certbot-apache $ certbot –apache $ certbot renew • Other clients • Also uses: o Certificate transparency o SSL observatory o Scan data repository ] SegRedes 18/19 - TLS Attacks - pbrandao [d cc Firewalls 12 Seg. Redes Misuses 25 • Phishing and fraud o Get certificate for amazom.com o See Let’s Encrypt and Comodo issue thousands of certificates for phishing by NetCraft and Let’s Encrypt The CA's Role in Fighting Phishing and Malware o Lessons From Top-to-Bottom Compromise of Brazilian Bank, by Kasperski ThreatPost . Modify DNS servers’ entries (ability to configure via web, get credentials via social eng.) . Modified entries pointed to attackers machines . Machines had Let’s Encrypt Certs . Even ATMs fell for it . “bank’s website was serving malware to each of its visitors” ] SegRedes 18/19 - TLS Attacks - pbrandao [d cc Certificate Transparency 26 • Open framework from Google • Components: o Logs of certificates issued (public, append only, crypto valid (Merkle Hash Trees), auditable) o Monitors for the logs to detect misuse o Auditors of the logs to validate currently seen certificates Image from Certificate Transparency ] SegRedes 18/19 - TLS Attacks - pbrandao [d cc Firewalls 13 Seg. Redes Certificate Image from Certificate Transparency 27 Transparency ] SegRedes 18/19 - TLS Attacks - pbrandao [d cc Certificate Image from Certificate Transparency 28 Transparency SCT: Signed Certificate Timestamp; which is simply a promise to add the certificate to the log within some time period.
Load more

Recommended publications
  • Cyber Security Trends: Aiming Ahead of the Target to Increase Security in 2017
    Cyber Security Trends: Aiming Ahead of the Target to Increase Security in 2017 A SANS Whitepaper Written by John Pescatore March 2017 Sponsored by Qualys ©2017 SANS™ Institute Introduction In security, change always equates to risk. Because change is constant, being aware of the key changes that will increase risk is a critical part of being proactive in cyber security. A simple equation for risk is the following: RISK THREAT VULNERABILITY ACTION Threats are Vulnerabilities Action consists of two malicious tactics are weaknesses components: and techniques that enable • Attacks that malicious actors (external that would cause those threats to or internal) take to launch threats damage to a succeed. business. • Prevention or mitigation efforts by security teams to reduce the attack aperture or increase speed of detection In reality, security teams control only half of the “Action” parameter. We can’t determine when threats will be developed or launched, and vulnerabilities are driven by weaknesses in people and technology. People change slowly, but technology changes rapidly, and business adoption of new technologies invariably brings new vulnerabilities that enable new threats. Understanding and anticipating business demand for emerging technologies is a key element in successful security programs. With each new wave of technology, threats tend to come in three forms: denial-of- service (DoS) attacks, cyber crime and attacks by nation-states. DoS Attacks When weaknesses in new technologies are exposed (generally by experimenters, academics and hacktivists), DoS attacks are the easiest to launch. They crash systems or cause data storms that bring networks to a halt. Cyber Crime Cyber criminals and the ecosystem that supports them refine attacks to focus on approaches that can lead to revenue, most commonly by stealing information that can be resold or support account fraud.
    [Show full text]
  • Quantitative Verification of Gossip Protocols for Certificate Transparency
    QUANTITATIVE VERIFICATION OF GOSSIP PROTOCOLS FOR CERTIFICATE TRANSPARENCY by MICHAEL COLIN OXFORD A thesis submitted to the University of Birmingham for the degree of DOCTOR OF PHILOSOPHY School of Computer Science College of Engineering and Physical Sciences University of Birmingham December 2020 2 Abstract Certificate transparency is a promising solution to publicly auditing Internet certificates. However, there is the potential of split-world attacks, where users are directed to fake versions of the log where they may accept fraudulent certificates. To ensure users are seeing the same version of a log, gossip protocols have been designed where users share and verify log-generated data. This thesis proposes a methodology of evaluating such protocols using probabilistic model checking, a collection of techniques for formally verifying properties of stochastic systems. It also describes the approach to modelling and verifying the protocols and analysing several aspects, including the success rate of detecting inconsistencies in gossip messages and its efficiency in terms of bandwidth. This thesis also compares different protocol variants and suggests ways to augment the protocol to improve performances, using model checking to verify the claims. To address uncertainty and unscalability issues within the models, this thesis shows how to transform models by allowing the probability of certain events to lie within a range of values, and abstract them to make the verification process more efficient. Lastly, by parameterising the models, this thesis shows how to search possible model configurations to find the worst-case behaviour for certain formal properties. 4 Acknowledgements To Auntie Mary and Nanny Lee. Writing this thesis could not have been accomplished after four tumultuous years alone.
    [Show full text]
  • Let's Encrypt: 30,229 Jan, 2018 | Let's Encrypt: 18,326 Jan, 2016 | Let's Encrypt: 330 Feb, 2017 | Let's Encrypt: 8,199
    Let’s Encrypt: An Automated Certificate Authority to Encrypt the Entire Web Josh Aas∗ Richard Barnes∗ Benton Case Let’s Encrypt Cisco Stanford University Zakir Durumeric Peter Eckersley∗ Alan Flores-López Stanford University Electronic Frontier Foundation Stanford University J. Alex Halderman∗† Jacob Hoffman-Andrews∗ James Kasten∗ University of Michigan Electronic Frontier Foundation University of Michigan Eric Rescorla∗ Seth Schoen∗ Brad Warren∗ Mozilla Electronic Frontier Foundation Electronic Frontier Foundation ABSTRACT 1 INTRODUCTION Let’s Encrypt is a free, open, and automated HTTPS certificate au- HTTPS [78] is the cryptographic foundation of the Web, providing thority (CA) created to advance HTTPS adoption to the entire Web. an encrypted and authenticated form of HTTP over the TLS trans- Since its launch in late 2015, Let’s Encrypt has grown to become the port [79]. When HTTPS was introduced by Netscape twenty-five world’s largest HTTPS CA, accounting for more currently valid cer- years ago [51], the primary use cases were protecting financial tificates than all other browser-trusted CAs combined. By January transactions and login credentials, but users today face a growing 2019, it had issued over 538 million certificates for 223 million do- range of threats from hostile networks—including mass surveil- main names. We describe how we built Let’s Encrypt, including the lance and censorship by governments [99, 106], consumer profiling architecture of the CA software system (Boulder) and the structure and ad injection by ISPs [30, 95], and insertion of malicious code of the organization that operates it (ISRG), and we discuss lessons by network devices [68]—which make HTTPS important for prac- learned from the experience.
    [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]
  • An Empirical Analysis of Email Delivery Security
    Neither Snow Nor Rain Nor MITM . An Empirical Analysis of Email Delivery Security Zakir Durumeric† David Adrian† Ariana Mirian† James Kasten† Elie Bursztein‡ Nicolas Lidzborski‡ Kurt Thomas‡ Vijay Eranti‡ Michael Bailey§ J. Alex Halderman† † University of Michigan ‡ Google, Inc. § University of Illinois, Urbana Champaign {zakir, davadria, amirian, jdkasten, jhalderm}@umich.edu {elieb, nlidz, kurtthomas, vijaye}@google.com [email protected] ABSTRACT tolerate unprotected communication at the expense of user security. The SMTP protocol is responsible for carrying some of users’ most Equally problematic, users face a medium that fails to alert clients intimate communication, but like other Internet protocols, authen- when messages traverse an insecure path and that lacks a mechanism tication and confidentiality were added only as an afterthought. In to enforce strict transport security. this work, we present the first report on global adoption rates of In this work, we measure the global adoption of SMTP security SMTP security extensions, including: STARTTLS, SPF, DKIM, and extensions and the resulting impact on end users. Our study draws DMARC. We present data from two perspectives: SMTP server from two unique perspectives: longitudinal SMTP connection logs configurations for the Alexa Top Million domains, and over a year spanning from January 2014 to April 2015 for Gmail, one of the of SMTP connections to and from Gmail. We find that the top mail world’s largest mail providers; and a snapshot of SMTP server providers (e.g., Gmail, Yahoo,
    [Show full text]
  • 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]
  • 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]
  • Practical Issues with TLS Client Certificate Authentication
    Practical Issues with TLS Client Certificate Authentication Arnis Parsovs Software Technology and Applications Competence Center, Estonia University of Tartu, Estonia [email protected] Abstract—The most widely used secure Internet communication Active security research is being conducted to improve standard TLS (Transport Layer Security) has an optional client password security, educate users on how to resist phishing certificate authentication feature that in theory has significant attacks, and to fix CA trust issues [1], [2]. However, the attacks security advantages over HTML form-based password authenti- mentioned above can be prevented or their impact can be cation. In this paper we discuss practical security and usability greatly reduced by using TLS client certificate authentication issues related to TLS client certificate authentication stemming (CCA), since the TLS CCA on the TLS protocol level protects from the server-side and browser implementations. In particular, we analyze Apache’s mod_ssl implementation on the server the client’s account on a legitimate server from a MITM side and the most popular browsers – Mozilla Firefox, Google attacker even in the case of a very powerful attacker who has Chrome and Microsoft Internet Explorer on the client side. We obtained a valid certificate signed by a trusted CA and who complement our paper with a measurement study performed in thus is able to impersonate the legitimate server. We believe Estonia where TLS client certificate authentication is widely used. that TLS CCA has great potential for improving Internet We present our recommendations to improve the security and security, and therefore in this paper we discuss current issues usability of TLS client certificate authentication.
    [Show full text]
  • Using the Audit App
    Using the Audit App Symantec CloudSOC Tech Note Tech Note — Using the Audit App Copyright statement Copyright (c) Broadcom. All Rights Reserved. Broadcom, the pulse logo, Connecting everything, and Symantec are among the trademarks of Broadcom. The term “Broadcom” refers to Broadcom Inc. and/or its subsidiaries. For more information, please visit www.broadcom.com. Broadcom reserves the right to make changes without further notice to any products or data herein to improve reliability, function, or design. Information furnished by Broadcom is believed to be accurate and reliable. However, Broadcom does not assume any liability arising out of the application or use of this information, nor the application or use of any product or circuit described herein, neither does it convey any license under its patent rights nor the rights of others. Copyright © 2021 Symantec Corp. 2 Tech Note — Using the Audit App Table of Contents Introduction Opening Audit Choosing data sources Viewing and filtering audit results Viewing summary results Viewing services, users, and destinations Filtering Audit Results Search Cloud Applications by Service, Category, Tag, Risk, User, Country, and Platform Saving and loading filters Using filter multi-select Configuring your services view Tagging cloud services Creating custom tags Viewing services tagged Ignore Adding comments for services Exporting Audit results Exporting ProxySG CPL block policy files from Audit Evaluating cloud services Viewing service information Customizing service rankings BRR Scoring for Individual Applications Customizing global service ratings Creating a custom BRR profile Comparing cloud services Exporting service and usage details Use of Attribute Filters in Find and Compare Services Copyright © 2021 Symantec Corp.
    [Show full text]
  • Can a TLS Certificate Be Phishy?
    Can a TLS Certificate Be Phishy? Kaspar Hageman1, Egon Kidmose1, Rene´ Rydhof Hansen2 and Jens Myrup Pedersen1 1Department of Electronic System, Aalborg University, Denmark 2Department of Computer Science, Aalborg University, Denmark Keywords: Phishing, Digital Certificate, Certificate Transparency, TLS. Abstract: This paper investigates the potential of using digital certificates for the detection of phishing domains. This is motivated by phishing domains that have started to abuse the (erroneous) trust of the public in browser padlock symbols, and by the large-scale adoption of the Certificate Transparency (CT) framework. This publicly accessible evidence trail of Transport Layer Security (TLS) certificates has made the TLS landscape more transparent than ever. By comparing samples of phishing, popular benign, and non-popular benign domains, we provide insight into the TLS certificates issuance behavior for phishing domains, focusing on the selection of the certificate authority, the validation level of the certificates, and the phenomenon of certificate sharing among phishing domains. Our results show that phishing domains gravitate to a relatively small selection of certificate authorities, and disproportionally to cPanel, and tend to rely on certificates with a low, and cheap, validation level. Additionally, we demonstrate that the vast majority of certificates issued for phishing domains cover more than only phishing domains. These results suggest that a more pro-active role of CAs and putting more emphasis on certificate revocation can have a crucial impact in the defense against phishing attacks. 1 INTRODUCTION web browsers and web servers. It raises the research question on whether TLS certificates can be labeled as Decades after its inception in the ’90s, phishing re- ‘phishy’ or benign in the same manner URLs and do- mains a significant problem.
    [Show full text]
  • Certificate Authority – Registration Authority (Verifies Cert Requests) – Validation Authority (Handles Revocation)
    11. Trust on the Web Blase Ur and David Cash February 5th, 2020 CMSC 23200 / 33250 Overview • Secure Sockets Layer (SSL) and its successor, Transport Layer Security (TLS) enable secure communication • Frequently encountered with web browsing (HTTPS) and more behind the scenes in app, VOIP, etc. What we want to defend against • People snooping on our communications – The contents of what we’re sending – Session tokens (see, e.g., Firesheep) • Person-in-the-middle attacks – We want to authenticate that we are talking to the right site, not an imposter – Use certificates inside a public-key infrastructure How we could obtain trust • Web of trust – People you already trust introduce you to people they trust – Can get complicated, doesn’t scale well – Infrequently seen in practice • Public-Key Infrastructure (PKI) – Certificates are issued by certificate authorities that bind cryptographic keys to identities Public-Key Infrastucture • Binding of keys to identities – Certificate authority – Registration authority (verifies cert requests) – Validation authority (handles revocation) Image from Wikimedia Foundation What does SSL look like to users? • Compare, e.g., the following: – https://www.google.com (normal certificate) – Go to Google images and then click on an image and see what happens (mixed content) – https://www.thawte.com (EV certificate) What does SSL look like to users? (From Felt et al. SOUPS 2016) How does PKI look to browsers? • Hundreds of trusted certificate authorities – Certificate authorities (CAs) sign the certificates binding
    [Show full text]
  • Blockchain-Based Certificate Transparency and Revocation
    Blockchain-based Certificate Transparency and Revocation Transparency? Ze Wang1;2;3, Jingqiang Lin1;2;3??, Quanwei Cai1;2, Qiongxiao Wang1;2;3, Jiwu Jing1;2;3, and Daren Zha1;2 1 State Key Laboratory of Information Security, Institute of Information Engineering, Chinese Academy of Sciences, Beijing 100093, China. 2 Data Assurance and Communication Security Research Center, Chinese Academy of Sciences, Beijing 100093, China. 3 School of Cyber Security, University of Chinese Academy of Sciences, Beijing 100049, China. {wangze,linjingqiang,caiquanwei,wangqiongxiao}@iie.ac.cn Abstract. Traditional X.509 public key infrastructures (PKIs) depend on certification authorities (CAs) to sign certificates, used in SSL/TLS to authenticate web servers and establish secure channels. However, recent security incidents indicate that CAs may (be compromised to) sign fraud- ulent certificates. In this paper, we propose blockchain-based certificate transparency and revocation transparency. Our scheme is compatible with X.509 PKIs but significantly reinforces the security guarantees of a certificate. The CA-signed certificates and their revocation status in- formation of an SSL/TLS web server are published by the subject (i.e., the web server) as a transaction, and miners of the community append it to the global certificate blockchain after verifying the transaction and mining a block. The certificate blockchain acts as append-only public logs to monitor CAs' certificate signing and revocation operations, and an SSL/TLS web server is granted with the cooperative control on its certificates to balance the absolute authority of CAs in traditional PKIs. We implement the prototype system with Firefox and Nginx, and the experimental results show that it introduces reasonable overheads.
    [Show full text]