DOCSLIB.ORG

A Technical Comparison of Ipsec and SSL

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text

Load more

A Technical Comparison of IPSec and SSL y Ab delNasir Alshamsi Takamichi Saito Tokyo University of Technology Abstract p osed but the most famous secure and widely de ployed are IPSec IP Security and SSL Secure So cket Layer IPSec IP Security and SSL SecureSocket Layer In this pap er we will provide a technical comparison have been the most robust and most potential tools of IPSec and SSL the similarities and the dierences available for securing communications over the Inter of the cryptographic prop erties The results of per net Both IPSec and SSL have advantages and short formance are based on comparing FreeSWAN as comings Yet no paper has been found comparing the IPSec and Stunnel as SSL two protocols in terms of characteristic and functional ity Our objective is to present an analysis of security and performancepr operties for IPSec and SSL IPSec IPSec is an IP layer proto col that enables the Intro duction sending and receiving of cryptographically protected packets of any kind TCPUDPICMPetc without any provides two kinds of crypto mo dication IPSec Securing data over the network is hard and compli graphic services Based on necessity IPSec can provide cated issue while the threat of data mo dication and condentiality and authenticity or it can provide data interruption is rising The goal of network security authenticity only is to provide condentiality integrity and authenticity Condentiality is keeping the data secret from the ESP Encapsulated SecurityPayload unintended listeners on the network Integrity is en suring that the received data is the data was actually AH Authentication Header sent Authenticity is proving the identity of the end ESP provides condentiality authenticity and in point to ensure that the end p ointistheintended entity tegrity protection for the communication and it is dis to communicate with tinguished by the ESP header attached to the packet The combination of these prop erties is the pillar of AH on the other hand ensures that authenticity and the security proto cols How to combine them is the integrity of the data is protected and it is identied ers Using a strong crypto question with many answ by the AH header attached to the packet ESP header graphic key with a weak authentication algorithm may includes the necessary information for decrypting and allow an attacker to disrupt the data Using a strong authenticating the data where AH header includes the authentication algorithm with a weak encryption algo necessary information required for authenticating the rithm may allowanattacker to decrypt the data Using protected data both strong authentication and encryption algorithm Establishing IPSec connection requires two phases protects the data but it will decrease the transmission Phase ISAKMP SA and Phase IPSec SA rate and could induce CPU consumption Therefore see table it is complicated to provide the b est protection the maximum throughput and the lowest overhead Phase With the recent development of the securitytools so many proto cols and powerful to ols have been pro Phase p erforms mutual authentication and pro Graduate Scho ol of System Electronics Katakurcho duces the encryption key required to protect Phase Hachiouji City Japan alshamsiaquatsitteuacjp y Phase has two mo des Main Mo de and Aggressive Department of Computer Science Katakurcho Ha Mo de The dierences between these two mo des are chiouji City Japan saitoccteuacjp the numb er of messages exchanged and the ID protec SA Security Asso ciation tion see table KE DieHellman exchanged public value Main Mo de Ni Nr the nonce I ID R the Initiator Resp onder ID CERT the certicate SIG I SIG R the signature for the Initiator Re sp onder resp ectively x x is optional Figure IPSec Main Mo de encryption must b egin after the header Key Exchange and Authentication AggressiveMode Various metho ds of Key Exchange mechanism and Authentication metho ds are supp orted by IPSec Key Exchange Metho d DH KINK Authentication Metho d Figure IPSec AggressiveMode PreShared Key PSK Phase Digital Signature Phase negotiates the cipher and authentication Public Key algorithm required to protect further transactions Phase has one mo de QuickMode KINK see The Hash Algorithms used by IPSec are MD and SHA see Table IPSec Mo de Phase Key Exchange Mo de Msg Exchanged Phase Main Mo de Figure IPSec QuickMode AggressiveMode Phase QuickMode The notations below were used to describ e Figure and IPSec Notation KINK is a Kerb eros based proto col that provides Key Ex change and authentication mechanism Not standardized yet HDR ISAKMP header such as RSA Digital Signature and DSA Digital Signature Server Authentication Table ID Protection ClientAuthentication Mo de Authentication Metho d ID Protection PSK yes Anonymous see Main RSADSA Digital Sig yes Client Authentication is in fact mutual authentica Public Key yes tion but the develop ers of SSL has referred to it as PSK no Client Authentication The Hash Algorithms used Aggressive RSADSA Digital Sig no by SSL are MD and SHA see Public Key yes An example of a SSL Handshake is describ ed in Fig ure SSL SSL Secure So cket Layer is an Application layer proto col SSL is mostly utilized to protect HTTP transactions and has b een used for other purp oses like IMAP and POP etc SSL is compatible with applica tions running only over TCPbut some mo dications are required for the applications to run over SSL Re centdevelopment of SSL software like Stunnel has added an easiness of use to SSL SSL is comp osed of the following proto cols Handshake proto col Change Cipher Sp ec proto col Alert proto col Application Data proto col Figure SSL Handshake Handshake proto col is used to p erform authentica tion and key exchanges Change Cipher Sp ec proto col Figure describ es SSL handshake in Client Authen is used to indicate that the chosen keys will now be tication The remove of the attached exchanges rep used Alert proto col is used for signaling errors and resents Server Authentication session closure Application Data proto col transmits and receives encrypted data SSL Notation ClientHello Client prop oses supp orted cipher suite Authentication Key Exchange and ServerHello Server sends chosen cipher suite Key Exchange Metho d Certicate Server sends certicate RSA CerticateRequest Server requests Clients Certi Client sends the pre master secret after encrypt cate ing it with Servers public key ServerHelloDone Server has sent all Handshake DH messages ClientandServer exchange DH public values and pro duce the pre master secret indep endently Certicate Client sends Certicate Other Key Exchange metho ds are used with SSL but ClientKeyExchange Client sends pre master secret in this pap er we will only refer to the ab ove mentioned encrypted with Servers public key metho ds Authentication Metho d ChangeCipherSp ec Client sends New chosen ci Kerb eros FORTEZZA pher suite will b e selected Finished nished message Table HMAC Algorithm Typ e ChangeCipherSp ec Server sends New chosen ci Proto col MAC Algorithm Hash Length pher suite will b e selected IPSec HMACSHA Byte HMACMD Byte Finished nished message SSL HMACSHA Byte HMACMD Byte Comparison of IPSec and SSL Authentication Algorithm to pro duce message digest The strength of the Hash IPSec supp orts the use of Digital Signature and the Algorithm is based on the length of the output see ta use of a Secret Key Algorithm where SSL supp orts ble only the use of Digital Signature The use of a random bit Secret Key is considered as strong as any other authentication metho ds In the absence of Digital Sig Connection Mo de nature algorithm IPSec can still b e implemented using the Secret Key but SSL cant b e implemented IPSec has two connection mo des Tunnel Mo de Authentication Metho d This is established b etween GatewaytoGateway GatewaytoHost and HosttoHost It establishes IPSec supp orts one typ e of authentication metho d a tunnel between the endp oint and it requires while SSL supp orts a various typ es of authentication adding a new IP header to the original packet They are describ ed in table and Transp ort Mo de Table IPSec Authentication Metho d Transp ort Mo de is HosttoHost connection The data b etween the twoentities are encrypted Authentication Metho d Authentication Algorithm The advantage of Tunnel Mo de is the elimination of Mutual Authentication PSK the overhead caused by eachchannel But the disad RSADSA Digital Signature vantage is what could happ en to the connection if the RSA Public Key key was compromised KINK SSL is a vice versa situation SSL is one connec tion p er one session typ e Each session is indep endent but the throughput could fall down as the number of sessions increases Table SSL Authentication Metho d Remote Access Authentication Metho d Authentication Algorithm Server Authentication RSA ChallengeResp onse IPSec encoun ters some problems when it comes to DSA Digital Signature remote access with PSK authentication in Main Mo de Client Authentication RSADSA Digital Signature In the case of PSK the ID is restricted to the IP ad Anonymous none dress only Since the IP address is not static the prop er shared key cant be lo cated and as a result Remote Host cant b e established Toavoid such incidentthe following metho ds are prop osed MAC Setting the remote host IP to and using one MAC Message Authentication Co de is used for au Shared Key for remote host access thenticating the exchanged messages after the connec Using Aggressive Mo de where the ID typ e is
Recommended publications
  • Not-Quite-So-Broken TLS Lessons in Re-Engineering a Security Protocol Specification and Implementation

    Not-Quite-So-Broken TLS Lessons in Re-Engineering a Security Protocol Specification and Implementation

    Not-quite-so-broken TLS Lessons in re-engineering a security protocol specification and implementation David Kaloper Meršinjak Hannes Mehnert Peter Sewell Anil Madhavapeddy University of Cambridge, Computer Labs Usenix Security, Washington DC, 12 August 2015 INT SSL23_GET_CLIENT_HELLO(SSL *S) { CHAR BUF_SPACE[11]; /* REQUEST THIS MANY BYTES IN INITIAL READ. * WE CAN DETECT SSL 3.0/TLS 1.0 CLIENT HELLOS * ('TYPE == 3') CORRECTLY ONLY WHEN THE FOLLOWING * IS IN A SINGLE RECORD, WHICH IS NOT GUARANTEED BY * THE PROTOCOL SPECIFICATION: * BYTE CONTENT * 0 TYPE \ * 1/2 VERSION > RECORD HEADER * 3/4 LENGTH / * 5 MSG_TYPE \ * 6-8 LENGTH > CLIENT HELLO MESSAGE Common CVE sources in 2014 Class # Memory safety 15 State-machine errors 10 Certificate validation 5 ASN.1 parsing 3 (OpenSSL, GnuTLS, SecureTransport, Secure Channel, NSS, JSSE) Root causes Error-prone languages Lack of separation Ambiguous and untestable specification nqsb approach Choice of language and idioms Separation and modular structure A precise and testable specification of TLS Reuse between specification and implementation Choice of language and idioms OCaml: a memory-safe language with expressive static type system Well contained side-effects Explicit flows of data Value-based Explicit error handling We leverage it for abstraction and automated resource management. Formal approaches Either reason about a simplified model of the protocol; or reason about small parts of OpenSSL. In contrast, we are engineering a deployable implementation. nqsb-tls A TLS stack, developed from scratch, with dual goals: Executable specification Usable TLS implementation Structure nqsb-TLS ML module layout Core Is purely functional: VAL HANDLE_TLS : STATE -> BUFFER -> [ `OK OF STATE * BUFFER OPTION * BUFFER OPTION | `FAIL OF FAILURE ] Core OCaml helps to enforce state-machine invariants.
  • Ipv6-Ipsec And

    Ipv6-Ipsec And

    IPSec and SSL Virtual Private Networks ITU/APNIC/MICT IPv6 Security Workshop 23rd – 27th May 2016 Bangkok Last updated 29 June 2014 1 Acknowledgment p Content sourced from n Merike Kaeo of Double Shot Security n Contact: [email protected] Virtual Private Networks p Creates a secure tunnel over a public network p Any VPN is not automagically secure n You need to add security functionality to create secure VPNs n That means using firewalls for access control n And probably IPsec or SSL/TLS for confidentiality and data origin authentication 3 VPN Protocols p IPsec (Internet Protocol Security) n Open standard for VPN implementation n Operates on the network layer Other VPN Implementations p MPLS VPN n Used for large and small enterprises n Pseudowire, VPLS, VPRN p GRE Tunnel n Packet encapsulation protocol developed by Cisco n Not encrypted n Implemented with IPsec p L2TP IPsec n Uses L2TP protocol n Usually implemented along with IPsec n IPsec provides the secure channel, while L2TP provides the tunnel What is IPSec? Internet IPSec p IETF standard that enables encrypted communication between peers: n Consists of open standards for securing private communications n Network layer encryption ensuring data confidentiality, integrity, and authentication n Scales from small to very large networks What Does IPsec Provide ? p Confidentiality….many algorithms to choose from p Data integrity and source authentication n Data “signed” by sender and “signature” verified by the recipient n Modification of data can be detected by signature “verification”
  • Mist Teleworker ME

    Mist Teleworker ME

    MIST TELEWORKER GUIDE ​ ​ ​ ​ ​ Experience the corporate network @ home DOCUMENT OWNERS: ​ ​ ​ ​ Robert Young – [email protected] ​ Slava Dementyev – [email protected] ​ Jan Van de Laer – [email protected] ​ 1 Table of Contents Solution Overview 3 How it works 5 Configuration Steps 6 Setup Mist Edge 6 Configure and prepare the SSID 15 Enable Wired client connection via ETH1 / Module port of the AP 16 Enable Split Tunneling for the Corp SSID 17 Create a Site for Remote Office Workers 18 Claim an AP and ship it to Employee’s location 18 Troubleshooting 20 Packet Captures on the Mist Edge 23 2 Solution Overview Mist Teleworker solution leverages Mist Edge for extending a corporate network to remote office workers using an IPSEC secured L2TPv3 tunnel from a remote Mist AP. In addition, MistEdge provides an additional RadSec service to securely proxy authentication requests from remote APs to provide the same user experience as inside the office. WIth Mist Teleworker solution customers can extend their corporate WLAN to employee homes whenever they need to work remotely, providing the same level of security and access to corporate resources, while extending visibility into user network experience and streamlining IT operations even when employees are not in the office. What are the benefits of the Mist Teleworker solution with Mist Edge compared to all the other alternatives? Agility: ● Zero Touch Provisioning - no AP pre-staging required, support for flexible all home coverage with secure Mesh ● Exceptional support with minimal support - leverage Mist SLEs and Marvis Actions Security: ● Traffic Isolation - same level of traffic control as in the office.
  • Configuring Secure Shell

    Configuring Secure Shell

    Configuring Secure Shell The Secure Shell (SSH) feature is an application and a protocol that provides a secure replacement to the Berkeley r-tools. The protocol secures sessions using standard cryptographic mechanisms, and the application can be used similarly to the Berkeley rexec and rsh tools. Two versions of SSH are available: SSH Version 1 and SSH Version 2. • Finding Feature Information, page 1 • Prerequisites for Configuring Secure Shell, page 1 • Restrictions for Configuring Secure Shell, page 2 • Information about SSH, page 2 • How to Configure Secure Shell, page 5 • Configuration Examples for Secure Shell, page 16 • Additional References for Secure Shell, page 18 • Feature Information for SSH, page 18 Finding Feature Information Your software release may not support all the features documented in this module. For the latest caveats and feature information, see Bug Search Tool and the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the feature information table at the end of this module. Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required. Prerequisites for Configuring Secure Shell The following are the prerequisites for configuring the switch for secure shell (SSH): • For SSH to work, the switch needs an Rivest, Shamir, and Adleman (RSA) public/private key pair. This is the same with Secure Copy Protocol (SCP), which relies on SSH for its secure transport.
  • Arxiv:1911.09312V2 [Cs.CR] 12 Dec 2019

    Arxiv:1911.09312V2 [Cs.CR] 12 Dec 2019

    Revisiting and Evaluating Software Side-channel Vulnerabilities and Countermeasures in Cryptographic Applications Tianwei Zhang Jun Jiang Yinqian Zhang Nanyang Technological University Two Sigma Investments, LP The Ohio State University [email protected] [email protected] [email protected] Abstract—We systematize software side-channel attacks with three questions: (1) What are the common and distinct a focus on vulnerabilities and countermeasures in the cryp- features of various vulnerabilities? (2) What are common tographic implementations. Particularly, we survey past re- mitigation strategies? (3) What is the status quo of cryp- search literature to categorize vulnerable implementations, tographic applications regarding side-channel vulnerabili- and identify common strategies to eliminate them. We then ties? Past work only surveyed attack techniques and media evaluate popular libraries and applications, quantitatively [20–31], without offering unified summaries for software measuring and comparing the vulnerability severity, re- vulnerabilities and countermeasures that are more useful. sponse time and coverage. Based on these characterizations This paper provides a comprehensive characterization and evaluations, we offer some insights for side-channel of side-channel vulnerabilities and countermeasures, as researchers, cryptographic software developers and users. well as evaluations of cryptographic applications related We hope our study can inspire the side-channel research to side-channel attacks. We present this study in three di- community to discover new vulnerabilities, and more im- rections. (1) Systematization of literature: we characterize portantly, to fortify applications against them. the vulnerabilities from past work with regard to the im- plementations; for each vulnerability, we describe the root cause and the technique required to launch a successful 1.
  • The State of the Authenticated Encryption 1

    The State of the Authenticated Encryption 1

    Ø Ñ ÅØÑØÐ ÈÙ ÐØÓÒ× DOI: 10.1515/tmmp-2016-0038 Tatra Mt. Math. Publ. 67 (2016), 167–190 THE STATE OF THE AUTHENTICATED ENCRYPTION Damian Vizar´ ABSTRACT. Ensuring confidentiality and integrity of communication remains among the most important goals of cryptography. The notion of authenticated encryption marries these two security goals in a single symmetric-key, crypto- graphic primitive. A lot of effort has been invested in authenticated encryption during the fifteen years of its existence. The recent Competition for Authenticated Encryption: Security, Applicability, and Robustness (CAESAR) has boosted the research activity in this area even more. As a result, the area of authenticated encryption boasts numerous results, both theoretically and practically oriented, and perhaps even greater number of constructions of authenticated encryption schemes. We explore the current landscape of results on authenticated encryption. We review the CEASAR competition and its candidates, the most popular con- struction principles, and various design goals for authenticated encryption, many of which appeared during the CAESAR competition. We also take a closer look at the candidate Offset Merkle-Damg˚ard (OMD). 1. Introduction Perhaps the two most fundamental goals of symmetric-key cryptography are providing confidentiality (privacy) and authenticity (together with integrity1) of messages that are being sent over an insecure channel. These two security properties of communication have traditionally been studied separately; they were formalized in separate notions [13], [14], and achieved by separate primitives (e.g., CBC mode for confidentiality and CBCMAC for authentication). c 2016 Mathematical Institute, Slovak Academy of Sciences. 2010 M a t h e m a t i c s Subject Classification: 94A60.
  • How Secure Is Textsecure?

    How Secure Is Textsecure?

    How Secure is TextSecure? Tilman Frosch∗y, Christian Mainkay, Christoph Badery, Florian Bergsmay,Jorg¨ Schwenky, Thorsten Holzy ∗G DATA Advanced Analytics GmbH firstname.lastname @gdata.de f g yHorst Gortz¨ Institute for IT-Security Ruhr University Bochum firstname.lastname @rub.de f g Abstract—Instant Messaging has gained popularity by users without providing any kind of authentication. Today, many for both private and business communication as low-cost clients implement only client-to-server encryption via TLS, short message replacement on mobile devices. However, until although security mechanisms like Off the Record (OTR) recently, most mobile messaging apps did not protect confi- communication [3] or SCIMP [4] providing end-to-end con- dentiality or integrity of the messages. fidentiality and integrity are available. Press releases about mass surveillance performed by intelli- With the advent of smartphones, low-cost short-message gence services such as NSA and GCHQ motivated many people alternatives that use the data channel to communicate, to use alternative messaging solutions to preserve the security gained popularity. However, in the context of mobile ap- and privacy of their communication on the Internet. Initially plications, the assumption of classical instant messaging, fueled by Facebook’s acquisition of the hugely popular mobile for instance, that both parties are online at the time the messaging app WHATSAPP, alternatives claiming to provide conversation takes place, is no longer necessarily valid. secure communication experienced a significant increase of new Instead, the mobile context requires solutions that allow for users. asynchronous communication, where a party may be offline A messaging app that claims to provide secure instant for a prolonged time.
  • Nist Sp 800-77 Rev. 1 Guide to Ipsec Vpns

    Nist Sp 800-77 Rev. 1 Guide to Ipsec Vpns

    NIST Special Publication 800-77 Revision 1 Guide to IPsec VPNs Elaine Barker Quynh Dang Sheila Frankel Karen Scarfone Paul Wouters This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-77r1 C O M P U T E R S E C U R I T Y NIST Special Publication 800-77 Revision 1 Guide to IPsec VPNs Elaine Barker Quynh Dang Sheila Frankel* Computer Security Division Information Technology Laboratory Karen Scarfone Scarfone Cybersecurity Clifton, VA Paul Wouters Red Hat Toronto, ON, Canada *Former employee; all work for this publication was done while at NIST This publication is available free of charge from: https://doi.org/10.6028/NIST.SP.800-77r1 June 2020 U.S. Department of Commerce Wilbur L. Ross, Jr., Secretary National Institute of Standards and Technology Walter Copan, NIST Director and Under Secretary of Commerce for Standards and Technology Authority This publication has been developed by NIST in accordance with its statutory responsibilities under the Federal Information Security Modernization Act (FISMA) of 2014, 44 U.S.C. § 3551 et seq., Public Law (P.L.) 113-283. NIST is responsible for developing information security standards and guidelines, including minimum requirements for federal information systems, but such standards and guidelines shall not apply to national security systems without the express approval of appropriate federal officials exercising policy authority over such systems. This guideline is consistent with the requirements of the Office of Management and Budget (OMB) Circular A-130. Nothing in this publication should be taken to contradict the standards and guidelines made mandatory and binding on federal agencies by the Secretary of Commerce under statutory authority.
  • Network Layer Security Adaptation Profile

    Network Layer Security Adaptation Profile

    Recommendation for Space Data System Standards NETWORK LAYER SECURITY ADAPTATION PROFILE RECOMMENDED STANDARD CCSDS 356.0-B-1 BLUE BOOK June 2018 Recommendation for Space Data System Standards NETWORK LAYER SECURITY ADAPTATION PROFILE RECOMMENDED STANDARD CCSDS 356.0-B-1 BLUE BOOK June 2018 RECOMMENDED STANDARD FOR NETWORK LAYER SECURITY ADAPTATION PROFILE AUTHORITY Issue: Recommended Standard, Issue 1 Date: June 2018 Location: Washington, DC, USA This document has been approved for publication by the Management Council of the Consultative Committee for Space Data Systems (CCSDS) and represents the consensus technical agreement of the participating CCSDS Member Agencies. The procedure for review and authorization of CCSDS documents is detailed in Organization and Processes for the Consultative Committee for Space Data Systems (CCSDS A02.1-Y-4), and the record of Agency participation in the authorization of this document can be obtained from the CCSDS Secretariat at the e-mail address below. This document is published and maintained by: CCSDS Secretariat National Aeronautics and Space Administration Washington, DC, USA E-mail: [email protected] CCSDS 356.0-B-1 Page i June 2018 RECOMMENDED STANDARD FOR NETWORK LAYER SECURITY ADAPTATION PROFILE STATEMENT OF INTENT The Consultative Committee for Space Data Systems (CCSDS) is an organization officially established by the management of its members. The Committee meets periodically to address data systems problems that are common to all participants, and to formulate sound technical solutions to these problems. Inasmuch as participation in the CCSDS is completely voluntary, the results of Committee actions are termed Recommended Standards and are not considered binding on any Agency.
  • Guidelines for the Secure Deployment of Ipv6

    Guidelines for the Secure Deployment of Ipv6

    Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks NIST Special Publication 800-119 Guidelines for the Secure Deployment of IPv6 Recommendations of the National Institute of Standards and Technology Sheila Frankel Richard Graveman John Pearce Mark Rooks C O M P U T E R S E C U R I T Y Computer Security Division Information Technology Laboratory National Institute of Standards and Technology Gaithersburg, MD 20899-8930 December 2010 U.S. Department of Commerce Gary Locke, Secretary National Institute of Standards and Technology Dr. Patrick D. Gallagher, Director GUIDELINES FOR THE SECURE DEPLOYMENT OF IPV6 Reports on Computer Systems Technology The Information Technology Laboratory (ITL) at the National Institute of Standards and Technology (NIST) promotes the U.S. economy and public welfare by providing technical leadership for the nation’s measurement and standards infrastructure. ITL develops tests, test methods, reference data, proof of concept implementations, and technical analysis to advance the development and productive use of information technology. ITL’s responsibilities include the development of technical, physical, administrative, and management standards and guidelines for the cost-effective security and privacy of sensitive unclassified information in Federal computer systems. This Special Publication 800-series reports on ITL’s research, guidance, and outreach efforts in computer security and its collaborative activities with industry, government, and academic organizations. National Institute of Standards and Technology Special Publication 800-119 Natl. Inst. Stand. Technol. Spec. Publ. 800-119, 188 pages (Dec. 2010) Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately.
  • Not-Quite-So-Broken TLS: Lessons in Re-Engineering a Security Protocol Specification and Implementation

    Not-Quite-So-Broken TLS: Lessons in Re-Engineering a Security Protocol Specification and Implementation

    Not-Quite-So-Broken TLS: Lessons in Re-Engineering a Security Protocol Specification and Implementation David Kaloper-Meršinjak, Hannes Mehnert, Anil Madhavapeddy, and Peter Sewell, University of Cambridge https://www.usenix.org/conference/usenixsecurity15/technical-sessions/presentation/kaloper-mersinjak This paper is included in the Proceedings of the 24th USENIX Security Symposium August 12–14, 2015 • Washington, D.C. ISBN 978-1-939133-11-3 Open access to the Proceedings of the 24th USENIX Security Symposium is sponsored by USENIX Not-quite-so-broken TLS: lessons in re-engineering a security protocol specification and implementation David Kaloper-Mersinjakˇ †, Hannes Mehnert†, Anil Madhavapeddy and Peter Sewell University of Cambridge Computer Laboratory [email protected] † These authors contributed equally to this work Abstract sensitive services, they are not providing the security we need. Transport Layer Security (TLS) is the most widely Transport Layer Security (TLS) implementations have a deployed security protocol on the Internet, used for au- history of security flaws. The immediate causes of these thentication and confidentiality, but a long history of ex- are often programming errors, e.g. in memory manage- ploits shows that its implementations have failed to guar- ment, but the root causes are more fundamental: the chal- antee either property. Analysis of these exploits typically lenges of interpreting the ambiguous prose specification, focusses on their immediate causes, e.g. errors in mem- the complexities inherent in large APIs and code bases, ory management or control flow, but we believe their root inherently unsafe programming choices, and the impos- causes are more fundamental: sibility of directly testing conformance between imple- mentations and the specification.
  • Limitations and Differences of Using Ipsec, TLS/SSL Or SSH As VPN

    Limitations and Differences of Using Ipsec, TLS/SSL Or SSH As VPN

    Exercise 1 question 1.4 Limitations and Differences of using IPsec, TLS/SSL or SSH as VPN-solution Ole Martin Dahl [[email protected]] October 29, 2004 Abstract Virtual private networks (VPNs) [1] [6] provide low-cost and secure access between hosts and/or networks. IPsec, TLS/SSL and SSH are popular technologies used to create VPNs. This article will point out some of the differences and limitations of using IPsec, TLS/SSL or SSH as VPN-solution. Introduction When selecting a VPN-solution three basic requirements must be assessed: Confidentiality Is necessary to protect the information that is being sent be- tween the communicating parties. A strong encryption algorithm is nec- essary to prevent an eavesdropper in reading confidential information in clear text. Integrity It is important to verify that the received information is the same as it was when it was sent to you. In the digital world this is solved through digital signatures and hash functions. Authentication It is necessary to verify that the information has come from whom it is supposed to, and that it is received by who is supposed to receive it, i.e. mutual authentication. All these requirements can be offered with IPsec[3], TLS/SSL[5] or SSH[4], but each requirement is not always necessary to fulfill in every context. In some cases the integrity requirement is the most important or in other cases confidentiality and getting perfect forward secrecy (PFS)1 is required. When choosing either IPsec, TLS/SSL or SSH care must be taken to achieve the required security from the protocol, each protocol can be configured to match different requirements.