X.509V3 Certificates for SSH Authentication
Total Page:16
File Type:pdf, Size:1020Kb
Load more
Recommended publications
-
Security + Encryption Standards
Security + Encryption Standards Author: Joseph Lee Email: joseph@ ripplesoftware.ca Mobile: 778-725-3206 General Concepts Forward secrecy / perfect forward secrecy • Using a key exchange to provide a new key for each session provides improved forward secrecy because if keys are found out by an attacker, past data cannot be compromised with the keys Confusion • Cipher-text is significantly different than the original plaintext data • The property of confusion hides the relationship between the cipher-text and the key Diffusion • Is the principle that small changes in message plaintext results in large changes in the cipher-text • The idea of diffusion is to hide the relationship between the cipher-text and the plaintext Secret-algorithm • A proprietary algorithm that is not publicly disclosed • This is discouraged because it cannot be reviewed Weak / depreciated algorithms • An algorithm that can be easily "cracked" or defeated by an attacker High-resiliency • Refers to the strength of the encryption key if an attacker discovers part of the key Data-in-transit • Data sent over a network Data-at-rest • Data stored on a medium Data-in-use • Data being used by an application / computer system Out-of-band KEX • Using a medium / channel for key-exchange other than the medium the data transfer is taking place (phone, email, snail mail) In-band KEX • Using the same medium / channel for key-exchange that the data transfer is taking place Integrity • Ability to determine the message has not been altered • Hashing algorithms manage Authenticity -
Configuring SSL for Services and Servers
Barracuda Web Application Firewall Configuring SSL for Services and Servers https://campus.barracuda.com/doc/4259877/ Configuring SSL for SSL Enabled Services You can configure SSL encryption for data transmitted between the client and the service. In the BASIC > Services page, click Edit next to a listed service and configure the following fields: Status – Set to On to enable SSL on your service. Status defaults to On for a newly created SSL enabled service. Certificate – Select a certificate presented to the browser when accessing the service. Note that only RSA certificates are listed here. If you have not created the certificate, select Generate Certificate from the drop-down list to generate a self-signed certificate. For more information on how to create self- signed certificates, see Creating a Client Certificate. If you want to upload a self-signed certificate, select Upload Certificate from the drop- down list. Provide the details about the certificate in the Upload Certificate dialog box. For information on how to upload a certificate, see Adding an SSL Certificate. Select ECDSA Certificate – Select an ECDSA certificate presented to the browser when accessing the service. SSL/TLS Quick Settings - Select an option to automatically configure the SSL/TLS protocols and ciphers. Use Configured Values - This option allows you to use the previously saved values. If the values are not saved, the Factory Preset option can be used. Factory Preset - This option allows you to enable TLS 1.1, TLS 1.2 and TLS 1.3 protocols without configuring override ciphers. Mozilla Intermediate Compatibility (Default, Recommended) - This configuration is a recommended configuration when you want to enable TLS 1.2 and TLS 1.3 and configure override ciphers for the same. -
26. Java 8 and 8 Security Controls 2-28-2017
New Security Control Enhancements Java 8 and 9 JIM MANICO Secure Coding Instructor www.manicode.com A little background dirt… [email protected] @manicode § Author of "Iron-Clad Java, Building Secure Web APPlications” from McGraw-Hill/Oracle-Press § 20+ years of software develoPment experience § OWASP Volunteer and Former OWASP Global Board Member § Kauai, Hawaii Resident Creative Commons MANICODE SECURITY 2 Java Enhancement ProPosals Creative Commons MANICODE SECURITY 3 'ohana (oh-ha-na) MEANING: Family. MOST COMMON USE: In referring to the WHOLE family. Creative Commons MANICODE SECURITY JEP IT UP § JEP stands for a JDK Enhancement Proposal § JEP's are how you drive change in the Java ecosystem. § Involvement is actually a lot of work. § Attention is given to PeoPle that put in the work. § The way to make imProvements or get ideas seriously considered is to do them via the JEP ProPosal Process. § Mike Ernst and Werner Dietl are good examPles. They are the duo that built type annotations which we we will talk about soon. Creative Commons MANICODE SECURITY 5 Java 9 Security JEP's Creative Commons MANICODE SECURITY 6 Java 9 Security Enhancements § There are 8 main security related JEPs for JDK 9: 219: Datagram Transport Layer Security (DTLS) 229: Create PKCS12 Keystores by Default 232: ImProve Secure APPlication Performance 244: TLS Application-Layer Protocol Negotiation Extension 246: Leverage CPU Instructions for GHASH and RSA 249: OCSP Stapling for TLS 287: Support SHA-3 Hash Algorithms 288: DisaBle SHA-1 Certificates Creative Commons MANICODE SECURITY 7 akamai (ah-ka-my) MEANING: Smart or Clever. MOST COMMON USE: Smart. -
12 Certificates-In-The-Wild Slides
Certificates in the wild Slides from • Dave Levin 414-spring2016 • Michelle Mazurek 414-fall2016 Certificates in the wild The lock icon indicates that the browser was able to authenticate the other end, i.e., validate its certificate Certificate chain Subject (who owns the public key) Common name: the URL of the subject Issuer (who verified the identity and signed this certificate) Serial number: Uniquely identifies this cert with respect to the issuer (look for this in CRLs) Signature algorithm: How the issuer will sign parts of the cert Not valid before/after: When to start and stop believing this cert (start & expiration dates) The public key: And the issuer’s signature of the public key Subject Alternate Names: Other URLs for which this cert should be considered valid. (wellsfargo.com is not the same as www.wellsfargo.com) Can include wildcards, e.g., *.google.com CRL & OCSP: Where to go to check if this certificate has been revoked Non-cryptographic checksums Certificate types Why are these different? This is an EV (extended validation) certificate; browsers show the full name for these kinds of certs Root CAs Root CAs in iOS9 • iOS9 ships with >50 that start with A-C • Full list at: https://support.apple.com/en-us/HT205205 Verifying certificates Browser Certificate “I’m because I say so!” Certificate “I’m because says so” Certificate “I’m because says so” Verifying certificates Browser Certificate “I’m because I say so!” Root key store Every device has one Certificate “I’m because says so” Must not contain malicious certificates Certificate -
An Overview of Public Key Infrastructure
AN OVERVIEW OF PUBLIC KEY INFRASTRUCTURE A Thesis Presented to the Faculty of San Diego State University In Partial Fulfillment of the Requirements for the Degree Master of Science in Applied Mathematics with a Concentration in Mathematical Theory of Communication Systems by Pavan Kandepet Fall 2013 iii Copyright c 2013 by Purushothaman Pavan Kandepet iv DEDICATION I would like to dedicate this thesis to my chair Dr. Carmelo Interlando for helping me extensively through the course of my study at San Diego State University. His valuable advice, insight and knowledge have helped me tremendously. I thank him for all the help he has provided. v ABSTRACT OF THE THESIS An Overview of Public Key Infrastructure by Pavan Kandepet Master of Science in Applied Mathematics with a Concentration in Mathematical Theory of Communication Systems San Diego State University, 2013 Security for electronic commerce has become increasingly demanding in recent years owing to its widespread adoption across geographically distributed systems. Public Key Infrastructure (PKI) is a relatively new technology with foundations in mathematics and which provides the necessary security features for digital commerce. The main goal of this work is to provide an introduction to PKI and how it can be used across geographically distributed systems. We start with an introduction to electronic commerce security and discuss its security concerns. This is followed by an introduction to cryptography, which sets the stage for the main chapter on PKI which introduces several components of this system in detail and its expectations. Next, certificates and certificate management, which are key components of electronic security, are discussed. -
On Robust Key Agreement Based on Public Key Authentication Feng Hao Thales E-Security, Cambridge, UK [email protected]
1 On Robust Key Agreement Based on Public Key Authentication Feng Hao Thales E-Security, Cambridge, UK [email protected] Abstract—This paper discusses public-key authenticated key Elliptic Curve Cryptography (ECC) [10]. Using ECC essen- agreement protocols. First, we critically analyze several authen- tially replaces the underlying (multiplicative) cyclic group ticated key agreement protocols and uncover various theoretical with another (additive) cyclic group defined over some elliptic and practical flaws. In particular, we present two new attacks on the HMQV protocol, which is currently being standardized curve. The essence of the protocol remains unchanged. by IEEE P1363. The first attack presents a counterexample to The acute problem with the Diffie-Hellman key agreement invalidate the basic authentication in HMQV. The second attack is that it is unauthenticated [2]. While secure against passive is applicable to almost all past schemes, despite that many of attackers, the protocol is inherently vulnerable to active attacks them have formal security proofs. These attacks highlight the such as the man-in-the-middle attack [6]. This is a serious lim- difficulty to design a crypto protocol correctly and suggest the caution one should always take. itation, which for many years has been motivating researchers We further point out that many of the design errors are caused to find a solution [3]–[5], [7], [9], [11], [13], [20]. by sidestepping an important engineering principle, namely To add authentication, we must start with assuming some “Do not assume that a message you receive has a particular shared secret. In general, there are two approaches. -
Secure Content Delivery with Amazon Cloudfront Improve the Security and Performance of Your Applications, While Lowering Your Content Delivery Costs
Secure Content Delivery with Amazon CloudFront Improve the Security and Performance of Your Applications, While Lowering Your Content Delivery Costs November 2016 This paper has been archived. For the latest technical content about secure content delivery with Amazon CloudFront, see https://docs-aws.amazon.com/whitepapers/latest/secure- content-delivery-amazon-cloudfront/secure-content-delivery- Archivedwith-amazon-cloudfront.html © 2016, Amazon Web Services, Inc. or its affiliates. All rights reserved. Notices This document is provided for informational purposes only. It represents AWS’s current product offerings and practices as of the date of issue of this document, which are subject to change without notice. Customers are responsible for making their own independent assessment of the information in this document and any use of AWS’s products or services, each of which is provided “as is” without warranty of any kind, whether express or implied. This document does not create any warranties, representations, contractual commitments, conditions or assurances from AWS, its affiliates, suppliers or licensors. The responsibilities and liabilities of AWS to its customers are controlled by AWS agreements, and this document is not part of, nor does it modify, any agreement between AWS and its customers. Archived Contents Introduction 1 Enabling Easy SSL/TLS Adoption 2 Using Custom SSL Certificates with SNI Custom SSL 3 Meeting Requirements for PCI Compliance and Industry Standard Apple iOS ATS 4 Improving Performance of SSL/TLS Connections 5 Terminating SSL Connections at the Edge 6 Supporting Session Tickets and OCSP Stapling 6 Balancing Security and Performance with Half Bridge and Full Bridge TLS Termination 7 Ensuring Asset Availability 8 Making SSL/TLS Adoption Economical 8 Conclusion 9 Further Reading 9 Notes 11 Archived Abstract As companies respond to cybercrime, compliance requirements, and a commitment to securing customer data, their adoption of Secure Sockets Layer/Transport Layer Security (SSL/TLS) protocols increases. -
Towards Certficateless Public Key Infrastructure: a Practical Alternative of the Traditional Pki
Journal of Theoretical and Applied Information Technology 15th January 2020. Vol.98. No 01 © 2005 – ongoing JATIT & LLS ISSN: 1992-8645 www.jatit.org E-ISSN: 1817-3195 TOWARDS CERTFICATELESS PUBLIC KEY INFRASTRUCTURE: A PRACTICAL ALTERNATIVE OF THE TRADITIONAL PKI 1EIHAB B.M. BASHIER, 2MOHAMMED A. HASSOUNA, 3TAOUFIK BEN JABEUR 1,3Dept of Mathematics, CAAS, Dhofar University, P.O. Box: 2509, Salalah, Oman 2Faculty of Computer Studies, National Ribat University, P.O. Box: 55, Khartoum, Sudan E-mail: [email protected], [email protected], [email protected] ABSTRACT Although the maturity and efficiency of the traditional PKI in managing the public keys of the enterprise users, it still has two central and interrelated challenges or limitations when the number of users get large: Scalability and Key management. These two challenges are of great concern to the organization's information security officials, who are working to manage public key infrastructure, especially when the organization's growth rate becomes large. The most two significant alternatives for the traditional PKI are: Identity-based Cryptography and Certificateless Cryptography. The Identity-based Cryptography (IBC) provides an easy way to manage the public keys of its users, without need to any kind of certificate and its managing overhead, where the identity of a user is its public key. The private key is provided by a trusted Key Generation Centre (KGC) after an authentication process that the user must follow. IBC has many security features, and there are many schemes in the literature that are based on this new concept. It has one major problem: The Key escrow, where all the private keys of the users are generated centrally by the KGC. -
Legacy of Heartbleed: MITM and Revoked Certificates
Legacy of Heartbleed: MITM and Revoked Certificates Alexey Busygin [email protected] NeoBIT Notable Private Key Leaks • 2010 – DigiCert Sdn Bhd. issued certificates with 512-bit keys • 2012 – Trustwave issued CA certificate for one of its customers DLP system • 2013 – DigiNotar CA was totally compromised • 2014 – Heartbleed bug caused certificate revocation storm. 500000+ certs to be revoked • 2015 – RSA-CRT private key leaks • 2017 – Cloudbleed bug in Cloudflare reverse proxies 2 Checking Certificate Revocation Status: Certificate Revocation Lists (CRL) • CAs publish CRLs – lists of revoked certificate serial numbers • Normally certificate contains URL of the corresponding CRL Why it’s not OK? CRLs are not appropriate for online checks: • Excess size (up to 1 MB) • Vulnerable to replay attacks 3 Checking Certificate Revocation Status: Online Certificate Status Protocol (OCSP) • CAs maintain OCSP responders answering with certificate revocation status • Normally certificate contains URL of the OCSP responder • OCSP provides optional replay attack protection Why it’s not OK? • Slows down connection establishment • Browsing history leaks to CA • OCSP responder is DDoS target 4 Checking Certificate Revocation Status: OCSP Stapling • No browsing history leaks • Choose one: o Replay attack protection o TLS server side OCSP response caching: Minimal impact on connection establishment time Reduced load on OCSP responder Why it’s not OK? • Stapled OCSP responses are optional and may be stripped by MITM • OCSP responder is DDoS target (if replay -
Chapter 1- Introduction
Authenticated Trusted Server Controlled Key Establishment Astha Keshariya A thesis submitted for degree of Doctor of Philosophy At the University of Otago, Dunedin New Zealand Date: 31st Dec 2010 This page is left blank. ii Keywords Three Party Authenticated Key Establishment, Trusted-server based Key Establishment Protocols, Authentication, Computer Security, Communications Security, Cryptography, Distributed Denial of Service resilience, Key Agreement Protocols, Key Establishment Protocols, Key Transport Protocols, Asymmetric Key Encryption, RSA based Authentication, Certificate based Authentication, Non-repudiation, Key escrow, Secure Mobile environment, Mobile Payments Systems, Provably Secure Protocols, 3-D Secure Protocol, Securing Mobile Communications, Secure Electronic Transactions, Properties of Key Establishment, Securing Real-time Wireless communications. iii Abstract The trusted server based key establishment protocols are well received by the research community. In this thesis we have discussed the benefits of asymmetric key based authentication scheme mediated by a trusted server which is known to all the users in a system. We have proposed a new trusted server based key establishment protocol (and named it AK-protocol) that makes use of well known certificate based authentication scheme (or ID based scheme when medium level of security is required), and the session key generation requires equal contribution of the trusted server and the participating clients. That is, the generation of ephemeral keys exclusively lies with -
Lynx: Authenticated Anonymous Real-Time Reporting of Electric Vehicle Information
2015 IEEE International Conference on Smart Grid Communications (SmartGridComm): Cyber Security and Privacy Lynx: Authenticated Anonymous Real-Time Reporting of Electric Vehicle Information Hongyang Li Gy¨orgy D´an Klara Nahrstedt University of Illinois Urbana-Champaign KTH Royal Institute of Technology University of Illinois Urbana-Champaign [email protected] [email protected] [email protected] Abstract—With the proliferation of electric vehicles (EVs), EV ture authentication. However, digital signature is computation- battery charging will be a significant load on the power grid, and ally expensive [7] and identity-revealing. Several works [8], [9] thus it will have to be optimized. Many proposed optimizations improve authentication efficiency by using symmetric keys, but rely on predicted EV information, such as future trip start time and battery State-of-Charge (SoC), for load management, charg- do not provide anonymity protection. Portunes [10] uses utility- ing scheduling, V2G profit optimization, etc. Prediction in turn issued pseudonyms to protect the EV’s privacy from third-party would benefit from real-time information about the EVs, while entities, but the utility knows the mapping between pseudonym they are on the road, i.e., before arriving at the charging facility. and EV’s true identity. Token-based approaches [11], [12] let A real-time reporting framework is thus necessary so that EVs the EV authenticate itself by revealing an authentication token can report status information to the utility in a timely fashion. In this paper we present Lynx, an authenticated anonymous real- to the utility, but the token revealing process is computationally time reporting protocol. Lynx allows an EV to send anonymous intensive and is not efficient for real-time reporting (e.g., in reports using pseudonyms that are unlinkable to its true identity. -
An Improved TLS Handshake Protocol LI Xian-Zhu , LIU
3rd International Conference on Machinery, Materials and Information Technology Applications (ICMMITA 2015) An Improved TLS handshake protocol LI Xian-Zhu1, LIU Jun2 1Postgraduate Team, Institute of Command information system, PLA University of Science and Technology,Nanjing 210007, China; 2.Institute of Command information system, PLAUST 13770828947@sina. cn Keywords: transport layer security, TLS, identity based encryption Abstract: The transport layer security protocol (TLS) used in the Internet exist complex certificate management shortcomings and highly handshake delay due to the use of the certificate, IBE avoid the above problems by not using the certificate. he article introduces the identity based encryption system into the TLS handshake protocol, and design a new handshake protocol. Analysis shows that, compared with the identity based encryption system on certificate based scheme, the cipher algorithm processing time increases slightly, communication amount has reduced, the handshake delay is significantly reduced and the protocol efficiency is greatly improved. Introduction Nowadays, the main protocol to realize secure communication in transport layer are SSL (Secure Socket Layer) and TLS (Transport Layer Security). SSL and TLS based on Reliable TCP and lie between transport layer and application layer. The TLS protocol is developed from the SSL protocol. So application layer could transport all kinds of data transparently to guarantee data’s security and confidentiality through TLS. Having been widely used on the Internet, TLS has been widely accepted in transport layer security. Nowadays, the long handshake delay is the important deficiency of TLS. Because TLS uses Public Key certificate in the authentication process between client and server, the process of certificate’s transmission and dispose result in the long handshake delay.