DOCSLIB.ORG

Guide to SSL Vpns

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Guide to SSL Vpns Special Publication 800-113 Guide to SSL VPNs Recommendations of the National Institute of Standards and Technology Sheila Frankel Paul Hoffman Angela Orebaugh Richard Park NIST Special Publication 800-113 Guide to SSL VPNs Recommendations of the National Institute of Standards and Technology Sheila Frankel Paul Hoffman Angela Orebaugh Richard Park 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 July 2008 U.S. Department of Commerce Carlos M. Gutierrez, Secretary National Institute of Standards and Technology James M. Turner, Deputy Director GUIDE TO SSL VPNS 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-113 Natl. Inst. Stand. Technol. Spec. Publ. 800-113, 87 pages (July 2008) Certain commercial entities, equipment, or materials may be identified in this document in order to describe an experimental procedure or concept adequately. Such identification is not intended to imply recommendation or endorsement by the National Institute of Standards and Technology, nor is it intended to imply that the entities, materials, or equipment are necessa rily the best available for the purpose. ii GUIDE TO SSL VPNS Acknowledgements The authors, Sheila Frankel of the National Institute of Standards and Technology (NIST), Paul Hoffman of the Virtual Private Network Consortium (VPNC), and Angela Orebaugh and Richard Park of Booz Allen Hamilton, wish to thank their colleagues who reviewed drafts of this document and contributed to its technical content, especially Elaine Barker, Jim St. Pierre and Tim Polk of NIST. The authors would like to acknowledge Tim Grance and Karen Scarfone of NIST for their keen and insightful assistance throughout the development of the document. The authors particularly want to thank Guy Snyder, Darren Hartman and Thang Phan of ICSA Labs for their careful review and valuable contributions to improving the quality of this publication. The authors would also like to express their thanks to Mike Hillhouse of Juniper Networks and Mahesh Jethanandani of Cisco for their worthwhile comments and suggestions. iii GUIDE TO SSL VPNS Table of Contents Executive Summary..............................................................................................................ES-1 1. Introduction ......................................................................................................................1-1 1.1 Authority...................................................................................................................1-1 1.2 Purpose and Scope .................................................................................................1-1 1.3 Audience ..................................................................................................................1-1 1.4 Document Structure .................................................................................................1-1 2. Network and Transport Layer Security ..........................................................................2-1 2.1 The Need for Network and Transport Layer Security...............................................2-1 2.2 Virtual Private Networking (VPN).............................................................................2-4 2.2.1 SSL Portal VPNs ..........................................................................................2-5 2.2.2 SSL Tunnel VPNs.........................................................................................2-5 2.2.3 Administering SSL VPNs..............................................................................2-5 2.3 Summary..................................................................................................................2-6 3. SSL VPN Fundamentals ..................................................................................................3-1 3.1 SSL VPN Architecture..............................................................................................3-1 3.2 SSL VPN Functions .................................................................................................3-2 3.3 SSL VPN Features and Security Services...............................................................3-3 3.3.1 Manageability ...............................................................................................3-4 3.3.2 High Availability and Scalability ....................................................................3-4 3.3.3 Portal Customization ....................................................................................3-5 3.3.4 Authentication...............................................................................................3-5 3.3.5 Encryption and Integrity Protection...............................................................3-6 3.3.6 Access Control .............................................................................................3-6 3.3.7 Endpoint Security Controls ...........................................................................3-8 3.3.8 Intrusion Prevention......................................................................................3-9 3.4 SSL Protocol Basics ................................................................................................3-9 3.4.1 Versions of SSL and TLS .............................................................................3-9 3.4.2 Cryptography Used in SSL Sessions .........................................................3-10 3.4.3 Authentication Used for Identifying SSL Servers........................................3-10 3.5 SSL VPN Challenges.............................................................................................3-11 3.6 Summary................................................................................................................3-12 4. SSL VPN Planning and Implementation.........................................................................4-1 4.1 Identify Requirements ..............................................................................................4-1 4.2 SSL VPNs and FIPS 140-2 Approval.......................................................................4-2 4.2.1 Versions of SSL............................................................................................4-3 4.2.2 Key Establishment Used by SSL..................................................................4-3 4.2.3 Hash Functions Used by SSL.......................................................................4-4 4.2.4 SSL Encryption.............................................................................................4-4 4.2.5 Certificates Used During SSL Negotiations..................................................4-4 4.3 Design the Solution..................................................................................................4-5 4.3.1 Design the Access Control Policy.................................................................4-6 4.3.2 Design the Endpoint Security Policy.............................................................4-9 4.3.3 Select the Authentication Methods .............................................................4-11 4.3.4 Design the Architecture ..............................................................................4-12 iv GUIDE TO SSL VPNS 4.3.5 Cryptography Policy and FIPS Compliance ...............................................4-23 4.3.6 Other Design Decisions..............................................................................4-23 4.3.7 Summary of Design Decisions ...................................................................4-24 4.4 Implement and Test Prototype...............................................................................4-25 4.4.1 Application and Client Interoperability ........................................................4-27 4.5 Deploy the Solution................................................................................................4-28 4.6 Manage the Solution ..............................................................................................4-29 4.7 Summary................................................................................................................4-30 5. SSL VPN Recommended Practices ................................................................................5-1 6. Alternatives to SSL VPNs................................................................................................6-1 6.1 Data Link Layer VPN Protocols ...............................................................................6-1 6.2 Network Layer VPN Protocols .................................................................................6-2
Load more

Recommended publications
  • Treasury X.509 Certificate Policy [TREASURYCP].” It Only Addresses Where an OLT PKI’S Requirements Differ from the Requirements for Basic Assurance in [TREASURYCP]
    UNCLASSIFIED UNITED STATES DEPARTMENT OF THE TREASURY DEPARTMENT OF THE TREASURY PUBLIC KEY INFRASTRUCTURE (PKI) X.509 CERTIFICATE POLICY VERSION 3.4 April 27, 2021 PKI Policy Management Authority (PMA) DATE DANIEL W. WOOD 1 UNCLASSIFIED DOCUMENT VERSION CONTROL Version Date Author(s) Description Reason For Change Bring the Treasury PKI Policy into Department of the compliance with FPKIPA change Treasury PKI Policy in 2.0 January 2008 James Schminky proposal requiring all cross certified RFC PKI Policies to be in RFC 3647 3647 format. format. As a result of mapping the Treasury Errata changes to sections PKI Policy to Federal Policy, a 2.2.1, 2.1 March 17, 2009 James Schminky number of minor changes and 4.8, 4.912, 5.5, and omissions where identified and 7.1.3. corrected. As a result of the PMA annual Errata changes to sections review a number of minor 5.6, and 6.3.2. Change corrections, Federal Bridge proposal changes to 2.4, 2.2 March 11, 2010 James Schminky Certification Authority (FBCA) 4.2.2, 5.1, 5.1.1 5.1.2.1, Policy Change Proposal Number: 5.4.4, 5.4.5, 6.1.6, 6.5.1, 2009-02 and 2010-01, and Treasury and 6.7. Change Proposal Change proposal changes As a result of FBCA Policy Change 2.3 April 15, 2010 James Schminky to 8.1 and 8.4. Proposal Number: 2010-02. Changes Proposal As a result of FBCA Policy Change Changes to 1.3.1.8, Proposal Numbers; 2010-3 thru 8 2.4 March 22, 2011 James Schminky 3.1.1&.2, 3.1.5, 3.2.3.1, and CPCA policy Change Proposal 4.7, 6.1.5, 8.1, and 9.4.3.
    [Show full text]
  • 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]
  • Symmetric Asynchronous Ratcheted Communication with Associated Data
    Symmetric Asynchronous Ratcheted Communication with Associated Data B Hailun Yan( ) and Serge Vaudenay Ecole´ Polytechnique F´ed´erale de Lausanne (EPFL), Lausanne, Switzerland {hailun.yan,serge.vaudenay}@epfl.ch Abstract. Following up mass surveillance and privacy issues, modern secure communication protocols now seek strong security, such as forward secrecy and post-compromise security, in the face of state exposures. To address this problem, ratcheting was thereby introduced, widely used in real-world messaging protocols like Signal. However, ratcheting comes with a high cost. Recently, Caforio et al. proposed pragmatic construc- tions which compose a weakly secure “light” protocol and a strongly secure “heavy” protocol, in order to achieve the so-called ratcheting on demand. The light protocol they proposed has still a high complexity. In this paper, we prove the security of the lightest possible proto- col we could imagine, which essentially encrypts then hashes the secret key. We prove it without any random oracle by introducing a new secu- rity notion in the standard model. Our protocol composes well with the generic transformation techniques by Caforio et al. to offer high security and performance at the same time. 1 Introduction A classic communication model usually assumes that the endpoints are secure while the adversary is on the communication channel. However, protocols in recent messaging applications are secured with end-to-end encryption due to the prevalence of malware and system vulnerabilities. They attempt to enable secure communication services by regularly updating (ratcheting) the encryption key. One notable example of ratcheting is the Signal protocol [14] by Open Whisper Systems with its double-ratchet algorithm.
    [Show full text]
  • 2012 07 26 Letter to Skype
    ! Privacy International 46 Bedford Row London WC1R 4LR United Kingdom +44 (0) 20 7242 2836 @privacyint UK Charity No. 1147471 Friday, 27 July 2012 Dear Mr Bates, I am writing to request further information about the privacy implications of recent developments at Skype, as reported in the Washington Post.1 We were delighted to read that you believe these reports are “inaccurate” and“could mislead the Skype community”, and that you want to “clear this up”. 2 The growth of Skype since its launch in 2003 to become the world's leading VoIP provider has been driven by service that is affordable, high quality and, above all, secure. From an early stage in its development, Skype has assured its customers of the security of their communications. Press releases and product descriptions from 2005 boast of "end-to-end encryption for superior privacy" that "nobody can intercept".3 In 2008, a spokesperson reassured users that “[w]e have not received any subpoenas or court orders asking us to perform a live interception or wiretap of Skype-to-Skype communications” and “[i]n any event, because of Skype's peer-to-peer architecture and encryption techniques, Skype would not be able to comply with such a request”.4 In short, a promise was made to Skype customers that the privacy of their conversations and file transfers would be protected. As I'm sure you know, among Skype's 663 million registered users across the world are human rights defenders and pro-democracy activists living under autocratic regimes. In an environment where most channels of communication
    [Show full text]
  • Secure Messaging1
    SoK: Secure Messaging1 Nik Unger∗, Sergej Dechandy Joseph Bonneauzx, Sascha Fahl{, Henning Perl{ Ian Goldberg∗, Matthew Smithy ∗ University of Waterloo, y University of Bonn, z Stanford University, x Electronic Frontier Foundation, { Fraunhofer FKIE Abstract—Motivated by recent revelations of widespread state insecure ways. However, as will become clear over the course surveillance of personal communication, many products now of this paper, the academic research community is also failing claim to offer secure and private messaging. This includes both a to learn some lessons from tools in the wild. large number of new projects and many widely adopted tools that have added security features. The intense pressure in the past two Furthermore, there is a lack of coherent vision for the future years to deliver solutions quickly has resulted in varying threat of secure messaging. Most solutions focus on specific issues models, incomplete objectives, dubious security claims, and a lack and have different goals and threat models. This is com- of broad perspective on the existing cryptographic literature on pounded by differing security vocabularies and the absence of secure communication. a unified evaluation of prior work. Outside of academia, many In this paper, we evaluate and systematize current secure messaging solutions and propose an evaluation framework for products mislead users by advertising with grandiose claims their security, usability, and ease-of-adoption properties. We con- of “military grade encryption” or by promising impossible sider solutions from academia, but also identify innovative and features such as self-destructing messages [7]–[10]. The recent promising approaches used “in the wild” that are not considered EFF Secure Messaging Scorecard evaluated tools for basic by the academic literature.
    [Show full text]
  • IM Security Documentation on Page Vi
    Trend Micro Incorporated reserves the right to make changes to this document and to the product described herein without notice. Before installing and using the product, review the readme files, release notes, and/or the latest version of the applicable documentation, which are available from the Trend Micro website at: http://docs.trendmicro.com/en-us/enterprise/trend-micro-im-security.aspx Trend Micro, the Trend Micro t-ball logo, Control Manager, MacroTrap, and TrendLabs are trademarks or registered trademarks of Trend Micro Incorporated. All other product or company names may be trademarks or registered trademarks of their owners. Copyright © 2016. Trend Micro Incorporated. All rights reserved. Document Part No.: TIEM16347/140311 Release Date: September 2016 Protected by U.S. Patent No.: Pending This documentation introduces the main features of the product and/or provides installation instructions for a production environment. Read through the documentation before installing or using the product. Detailed information about how to use specific features within the product may be available at the Trend Micro Online Help Center and/or the Trend Micro Knowledge Base. Trend Micro always seeks to improve its documentation. If you have questions, comments, or suggestions about this or any Trend Micro document, please contact us at [email protected]. Evaluate this documentation on the following site: http://www.trendmicro.com/download/documentation/rating.asp Privacy and Personal Data Collection Disclosure Certain features available in Trend Micro products collect and send feedback regarding product usage and detection information to Trend Micro. Some of this data is considered personal in certain jurisdictions and under certain regulations.
    [Show full text]
  • Investigating Mobile Messaging Security
    Technische Universitat¨ Munchen¨ Department of Informatics Interdisciplinary Project in Electrical Engineering Investigating Mobile Messaging Security Elias Hazboun Technische Universitat¨ Munchen¨ Department of Informatics Interdisciplinary Project in Electrical Engineering Investigating Mobile Messaging Security Untersuchung von Mobile Messaging Sicherheit Author Elias Hazboun Supervisor Prof. Dr.-Ing. Georg Carle Advisor Dr. Matthias Wachs, Quirin Scheitle Date April 27, 2016 Informatik VIII Chair for Network Architectures and Services Abstract In this report we document our work in analyzing the security of a selection of mobile messaging apps. Focusing on network based security, we studied traffic generated by the apps to gain an understanding of the current state of applying encryption and authentication protocols. Our findings show a positive trend in security with developers steadily improving security with newer app updates partly due to the increased scrutiny from the community and academia. Although not all apps analyzed had perfect state of the art security properties, none have shown any major vulnerabilities exploited by normal adversaries. It was also evident that only one app - namely TextSecure - is using the industry standard TLS for server-client authentication and security while others have opted for custom made protocols and algorithms. I Contents 1 Introduction 1 1.1 Research Question . .2 1.2 Outline . .2 2 Background and Related Work 3 2.1 Methodology . .3 2.1.1 App Selection . .3 2.1.2 Approach . .3 2.2 Definition of Security Concepts . .4 2.2.1 Layers of Encryption . .4 2.2.2 Transport Layer Security Protocol (TLS) . .5 2.2.3 Perfect Forward Secrecy (PFS) . .5 2.2.4 Asynchronous Messaging Security .
    [Show full text]
  • Microsoft DNS
    1 a. Domain Name Service (DNS) encompassing Microsoft DNS From Wikipedia, the free encyclopedia Jump to: navigation, search Microsoft DNS is the name given to the implementation of domain name system services provided in Microsoft Windows operating systems. Contents [hide] 1 Overview 2 DNS lookup client o 2.1 The effects of running the DNS Client service o 2.2 Differences from other systems 3 Dynamic DNS Update client 4 DNS server o 4.1 Common issues 5 See also 6 References 7 External links [edit] Overview The Domain Name System support in Microsoft Windows NT, and thus its derivatives Windows 2000, Windows XP, and Windows Server 2003, comprises two clients and a server. Every Microsoft Windows machine has a DNS lookup client, to perform ordinary DNS lookups. Some machines have a Dynamic DNS client, to perform Dynamic DNS Update transactions, registering the machines' names and IP addresses. Some machines run a DNS server, to publish DNS data, to service DNS lookup requests from DNS lookup clients, and to service DNS update requests from DNS update clients. The server software is only supplied with the server versions of Windows. [edit] DNS lookup client Applications perform DNS lookups with the aid of a DLL. They call library functions in the DLL, which in turn handle all communications with DNS servers (over UDP or TCP) and return the final results of the lookup back to the applications. 2 Microsoft's DNS client also has optional support for local caching, in the form of a DNS Client service (also known as DNSCACHE). Before they attempt to directly communicate with DNS servers, the library routines first attempt to make a local IPC connection to the DNS Client service on the machine.
    [Show full text]
  • Zfone: a New Approach for Securing Voip Communication
    Zfone: A New Approach for Securing VoIP Communication Samuel Sotillo [email protected] ICTN 4040 Spring 2006 Abstract This paper reviews some security challenges currently faced by VoIP systems as well as their potential solutions. Particularly, it focuses on Zfone, a vendor-neutral security solution developed by PGP’s creator, Phil Zimmermann. Zfone is based on the Z Real-time Transport Protocol (ZRTP), which is an extension of the Real-time Transport Protocol (RTP). ZRTP offers a very simple and robust approach to providing protection against the most common type of VoIP threats. Basically, the protocol offers a mechanism to guarantee high entropy in a Diffie- Hellman key exchange by using a session key that is computed through the hashing several secrets, including a short authentication string that is read aloud by callers. The common shared secret is calculated and used only for one session at a time. However, the protocol allows for a part of the shared secret to be cached for future sessions. The mechanism provides for protection for man-in-the-middle, call hijack, spoofing, and other common types of attacks. Also, this paper explores the fact that VoIP security is a very complicated issue and that the technology is far from being inherently insecure as many people usually claim. Introduction Voice over IP (VoIP) is transforming the telecommunication industry. It offers multiple opportunities such as lower call fees, convergence of voice and data networks, simplification of deployment, and greater integration with multiple applications that offer enhanced multimedia functionality [1]. However, notwithstanding all these technological and economic opportunities, VoIP also brings up new challenges.
    [Show full text]
  • Cryptographic Control Standard, Version
    Nuclear Regulatory Commission Office of the Chief Information Officer Computer Security Standard Office Instruction: OCIO-CS-STD-2009 Office Instruction Title: Cryptographic Control Standard Revision Number: 2.0 Issuance: Date of last signature below Effective Date: October 1, 2017 Primary Contacts: Kathy Lyons-Burke, Senior Level Advisor for Information Security Responsible Organization: OCIO Summary of Changes: OCIO-CS-STD-2009, “Cryptographic Control Standard,” provides the minimum security requirements that must be applied to the Nuclear Regulatory Commission (NRC) systems which utilize cryptographic algorithms, protocols, and cryptographic modules to provide secure communication services. This update is based on the latest versions of the National Institute of Standards and Technology (NIST) Guidance and Federal Information Processing Standards (FIPS) publications, Committee on National Security System (CNSS) issuances, and National Security Agency (NSA) requirements. Training: Upon request ADAMS Accession No.: ML17024A095 Approvals Primary Office Owner Office of the Chief Information Officer Signature Date Enterprise Security Kathy Lyons-Burke 09/26/17 Architecture Working Group Chair CIO David Nelson /RA/ 09/26/17 CISO Jonathan Feibus 09/26/17 OCIO-CS-STD-2009 Page i TABLE OF CONTENTS 1 PURPOSE ............................................................................................................................. 1 2 INTRODUCTION ..................................................................................................................
    [Show full text]
  • Implementing PKI Services on Z/OS
    Front cover Implementing PKI Services on z/OS Installation of PKI and all of its prerequistes on z/OS An example of the PKI Exit PKI’s use of ICSF to store Master Key Chris Rayns Theo Antoff Jack Jones Patrick Kappeler Vicente Ranieri Roland Trauner ibm.com/redbooks International Technical Support Organization Implementing PKI Services on z/OS February 2004 SG24-6968-00 Note: Before using this information and the product it supports, read the information in “Notices” on page vii. First Edition (February 2004) This edition applies to z/OS Version 1, Release 3. © Copyright International Business Machines Corporation 2004. All rights reserved. Note to U.S. Government Users Restricted Rights -- Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM Corp. Contents Notices . vii Trademarks . viii Preface . ix The team that wrote this redbook. ix Become a published author . x Comments welcome. xi Chapter 1. Security Server PKI Services. 1 1.1 Overview of digital certificate. 2 1.2 The PKIX standards . 4 1.2.1 CA hierarchy . 6 1.2.2 The X.509 certificate and Certificate Revocation List . 9 1.2.3 The x.509 v3 certificate extension fields . 14 1.2.4 Certificate and CRL appearance. 17 1.3 The z/OS PKI Services . 21 1.3.1 Security Server PKI Services in z/OS . 21 1.3.2 Prerequisite products . 22 1.3.3 Requests supported by z/OS PKI Services. 23 1.3.4 Browser and server certificates. 24 1.3.5 The z/OS PKI Services architecture . 26 1.4 Security Server PKI Services enhancement in z/OS V1R4.
    [Show full text]
  • Amazon Trust Services Certificate Policy
    Certificate Policy Version 1.0.9 1 1 INTRODUCTION ................................................................................................................................................... 13 1.1 Overview ...................................................................................................................................................... 13 1.1.1 Compliance ............................................................................................................................................ 13 1.1.2 Types of Certificates .............................................................................................................................. 13 1.1.2.1 CA-Certificates .............................................................................................................................. 13 1.1.2.1.1 Missing Heading ........................................................................................................................ 14 1.1.2.1.2 Missing Heading ........................................................................................................................ 14 1.1.2.1.3 Terminus CA-Certificates .......................................................................................................... 14 1.1.2.1.4 Policy CA-Certificates ................................................................................................................ 14 1.1.2.1.5 Technically Constrained CA-Certificates ..................................................................................
    [Show full text]