DOCSLIB.ORG

Applied Crypto Hardening

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
Applied Crypto Hardening Applied Crypto HarDENING WOLFGANG BrEyha, David Durvaux, TOBIAS Dussa, L. AarON Kaplan, Florian Mendel, Christian Mock, Manuel Koschuch, Adi Kriegisch, Ulrich Pöschl, Ramin Sabet, BerG San, Ralf Schlatterbeck, Thomas Schreck, AleXANDER Würstlein, AarON Zauner, Pepi Zawodsky (University OF Vienna, CERT.be, KIT-CERT, CERT.at, A-SIT/IAIK, CORetec.at, FH Campus Wien, VRVis, MilCERT Austria, A-Trust, Runtux.com, Friedrich-AleXANDER University Erlangen-NurEMBERg, azet.org, maclemon.at) NoVEMBER 10, 2016 Do NOT TALK UNENCRYPTED Applied Crypto HarDENING PAGE 2 OF 111 AcknoWLEDGEMENTS WE WOULD LIKE TO EXPRESS OUR THANKS TO THE FOLLOWING REVIEWERS AND PEOPLE WHO HAVE GENEROUSLY OffERED THEIR TIME AND INTEREST (in ALPHABETICAL ORder): BrOwn, Scott Pacher, Christoph Brulebois, Cyril Palfrader, Peter Dirksen-Thedens, Mathis Pape, TOBIAS (layout) DulaunoY, AleXANDRE Petukhova, Anna (Logo) Gühring Philipp Pichler, Patrick Grigg, IAN Riebesel, Nicolas Haslinger, Gunnar Roeckx, Kurt Huebl, AxEL Roesen, Jens Kovacic, Daniel Rublik, Martin Lenzhofer, Stefan Schüpany, Mathias Lorünser, Thomas Schwarz, René («DigNative») Maass, Max Seidl, Eva (PDF layout) Mehlmauer, Christian VAN Horenbeeck, Maarten Millauer, TOBIAS Wagner, Sebastian («sebix») Mirbach, AndrEAS Zangerl, AleXANDER O’Brien, Hugh The REVIEWERS DID REVIEW PARTS OF THE DOCUMENT IN THEIR AREA OF Expertise; ALL REMAINING ERRORS IN THIS DOCUMENT ARE THE SOLE RESPONSIBILITY OF THE PRIMARY authors. Applied Crypto HarDENING PAGE 3 OF 111 AbstrACT “Unfortunately, THE COMPUTER SECURITY AND CRYPTOLOGY COMMUNITIES HAVE DRIFTED APART OVER THE LAST 25 years. Security PEOPLE DON’T ALWAYS UNDERSTAND THE AVAILABLE CRYPTO tools, AND CRYPTO PEOPLE DON’T ALWAYS UNDERSTAND THE Real-world PRoblems.” — Ross Anderson IN [And08] This GUIDE AROSE OUT OF THE NEED FOR SYSTEM ADMINISTRATORS TO HAVE AN updated, solid, WELL Re- SEARCHED AND thought-thrOUGH GUIDE FOR CONfiGURING SSL, PGP, SSH AND OTHER CRYPTOGRAPHIC TOOLS IN THE post-SnoWDEN age. TRIGGERED BY THE NSA LEAKS IN THE SUMMER OF 2013, MANY SYSTEM admin- ISTRATORS AND IT SECURITY OffiCERS SAW THE NEED TO STRENGTHEN THEIR ENCRYPTION settings. This GUIDE IS SPECIfiCALLY WRITTEN FOR THESE SYSTEM ADMINISTRators. As Schneier NOTED IN [Sch13a], IT SEEMS THAT INTELLIGENCE AGENCIES AND ADVERSARIES ON THE INTERNET ARE NOT BREAKING SO MUCH THE MATHEMATICS OF ENCRYPTION PER se, BUT RATHER USE SOFTWARE AND HARDWARE weaknesses, SUBVERT STANDARDIZATION PRocesses, PLANT BACKdoors, RIG RANDOM NUMBER GENERATORS AND MOST OF ALL EXPLOIT CARELESS SETTINGS IN SERVER CONfiGURATIONS AND ENCRYPTION SYSTEMS TO LISTEN IN ON PRIVATE communications. WORST OF all, MOST COMMUNICATION ON THE INTERNET IS NOT ENCRYPTED AT ALL BY DEFAULT (for SMTP, OPPORTUNISTIC TLS WOULD BE A solution). This GUIDE CAN ONLY ADDRESS ONE ASPECT OF SECURING OUR INFORMATION systems: GETTING THE CRYPTO SETTINGS RIGHT TO THE BEST OF THE AUTHORS’ CURRENT KNOwledge. Other attacks, AS THE ABOVE mentioned, REQUIRE DIffERENT PROTECTION SCHEMES WHICH ARE NOT COVERED IN THIS guide. This GUIDE IS NOT AN INTRODUCTION TO CRYPTOGRAPHY. For BACKGROUND INFORMATION ON CRYPTOGRAPHY AND CRYPTOANALYSIS WE WOULD LIKE TO REFER THE READER TO THE REFERENCES IN APPENDIXB ANDC AT THE END OF THIS document. The FOCUS OF THIS GUIDE IS MERELY TO GIVE CURRENT BEST PRACTICES FOR CONfiGURING COMPLEX CIPHER SUITES AND RELATED PARAMETERS IN A . The GUIDE TRIES TO STAY AS CONCISE AS IS pos- COPY & paste-able MANNER SIBLE FOR SUCH A COMPLEX TOPIC AS CRYPTOGRAPHY. NaturALLY, IT CAN NOT BE complete. TherE ARE MANY EXCELLENT GUIDES [IS12, fSidIB13, ENI13] AND BEST PRACTICE DOCUMENTS AVAILABLE WHEN IT COMES TO CRYPTOGRAPHY. HoWEVER NONE OF THEM FOCUSES SPECIfiCALLY ON WHAT AN AVERAGE SYSTEM ADMINISTRATOR NEEDS FOR HARDENING HIS OR HER SYSTEMS’ CRYPTO settings. This GUIDE TRIES TO fiLL THIS gap. Contents 1. INTRODUCTION 7 1.1. Audience.............................................7 1.2. Related PUBLICATIONS......................................7 1.3. HoW TO READ THIS GUIDE.....................................7 1.4. Disclaimer AND SCOPE......................................8 1.5. Methods............................................. 10 2. PrACTICAL RECOMMENDATIONS 11 2.1. WEBSERVERS........................................... 11 2.1.1. Apache.......................................... 11 2.1.2. LIGHTTPD.......................................... 12 2.1.3. NGINX........................................... 14 2.1.4. CherOKEE......................................... 16 2.1.5. MS IIS........................................... 18 2.2. SSH................................................ 22 2.2.1. OpenSSH......................................... 22 2.2.2. Cisco ASA........................................ 24 2.2.3. Cisco IOS......................................... 25 2.3. Mail Servers........................................... 25 2.3.1. TLS USAGE IN MAIL SERVER PROTOCOLS.......................... 26 2.3.2. Recommended CONfiGURATION............................. 26 2.3.3. DoVECOT......................................... 27 2.3.4. cyrus-imapd....................................... 28 2.3.5. PostfiX.......................................... 30 2.3.6. Exim........................................... 32 2.3.7. Cisco ESA/IRonPort................................... 36 2.4. VPNs............................................... 39 2.4.1. IPsec........................................... 39 2.4.2. Check Point FireWall-1................................. 41 2.4.3. OpenVPN........................................ 45 2.4.4. PPTP........................................... 47 2.4.5. Cisco ASA........................................ 47 2.4.6. Openswan........................................ 49 2.4.7. TINC............................................ 51 2.5. PGP/GPG - PrETTY Good Privacy................................ 51 2.6. IPMI, ILO AND OTHER LIGHTS OUT MANAGEMENT SOLUTIONS................... 52 2.7. INSTANT Messaging Systems.................................. 52 2.7.1. GenerAL SERVER CONfiGURATION RECOMMENDATIONS.................. 52 2.7.2. EJABBERD......................................... 53 2.7.3. Chat PRIVACY - Off-the-RecorD Messaging (OTR).................. 56 2.7.4. Charybdis........................................ 57 2.7.5. SILC............................................ 57 2.8. Database Systems....................................... 57 2.8.1. OrACLE.......................................... 57 Applied Crypto HarDENING PAGE 5 OF 111 Contents Contents 2.8.2. MySQL.......................................... 58 2.8.3. DB2............................................ 59 2.8.4. PostgreSQL....................................... 59 2.9. INTERCEPTING PROXY SOLUTIONS AND REVERSE PROXIES..................... 60 2.9.1. Bluecoat......................................... 61 2.9.2. HAPrOXY......................................... 62 2.9.3. Pound.......................................... 64 2.9.4. STUNNEL.......................................... 65 2.10.KerberOS............................................. 66 2.10.1.OvervieW......................................... 66 2.10.2.IMPLEMENTATIONS.................................... 68 3. Theory 71 3.1. OvervieW............................................. 71 3.2. Cipher SUITES........................................... 71 3.2.1. ArCHITECTURAL OVERVIEW................................. 71 3.2.2. ForwarD SecrECY.................................... 73 3.2.3. Recommended CIPHER SUITES............................. 73 3.2.4. Compatibility...................................... 75 3.3. Random Number GenerATORS................................. 76 3.3.1. When RANDOM NUMBER GENERATORS FAIL....................... 76 3.3.2. Linux........................................... 77 3.3.3. Recommendations................................... 77 3.4. KeYLENGTHS............................................ 78 3.5. A NOTE ON Elliptic Curve CryptogrAPHY............................ 79 3.6. A NOTE ON SHA-1......................................... 80 3.7. A NOTE ON DiffiE Hellman KeY ExCHANGES.......................... 80 3.8. Public KeY INFRASTRUCTURES................................... 81 3.8.1. CertifiCATE Authorities................................. 81 3.8.2. HarDENING PKI ...................................... 83 3.8.3. CertifiCATION Authorization RecorDS......................... 83 3.9. TLS AND ITS SUPPORT MECHANISMS............................... 84 3.9.1. HTTP Strict TRANSPORT Security (HSTS)........................ 85 3.9.2. HTTP Public KeY Pinning (HPKP)........................... 87 A. TOOLS 93 A.1. SSL & TLS............................................. 93 A.2. KeY LENGTH............................................ 94 A.3. RNGs............................................... 94 A.4. Guides.............................................. 94 B. Links 95 C. Suggested Reading 96 D. Cipher Suite Name Cross-ReferENCE 97 E. Further RESEARCH 106 E.1. SoftwarE NOT COVERED BY THIS GUIDE.............................. 106 INDEX 111 Applied Crypto HarDENING PAGE 6 OF 111 1. INTRODUCTION 1.1. Audience Sysadmins. Sysadmins. Sysadmins. TheY ARE A FORce-multiplier. 1.2. Related PUBLICATIONS Ecrypt II [IS12], ENISA’S REPORT ON Algorithms, KEY SIZES AND PARAMETERS [ENI13] AND BSI’S TECHNISCHE Richtlinie TR-02102 [fSidIB13] ARE GREAT PUBLICATIONS WHICH ARE MORE IN DEPTH THAN THIS guide. HoWEver, THIS GUIDE HAS A DIffERENT APPRoach: IT FOCUSES ON FOR SYSTEM COPY & paste-able SETTINGS ADMINISTRators, EffECTIVELY BREAKING DOWN THE COMPLEXITY IN THE ABOVE MENTIONED REPORTS TO AN EASY TO USE FORMAT FOR
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]
  • Email Transport Encryption STARTTLS Vs. DANE Vs. MTA-STS
    Email Transport Encryption STARTTLS vs. DANE vs. MTA-STS Delimitation This document deals with the encrypted transport of messages between two email servers. Encryption during transport is crucial for a basic level of security for the exchange of messages. The exchange of messages between an email client and a server or the end-to-end encryption of messages are not covered in this article. If the aim is to create a secure overall system, these aspects should be considered in addition to the recommendations in this article. Initial situation When the first standard for the Simple Mail Transfer Protocol (in short: SMTP) was adopted, encryption of the transport was not included. All messages were exchanged as plain text between the servers. They were thus basically readable for anyone who could tap into the data exchange between the two servers. This only changed with the introduction of the SMTP Service Extensions for Extend SMTP (ESMTP for short), which made it possible to choose encrypted transport as an opportunistic feature of data exchange. Opportunistic, because it had to be assumed that not all servers would be able to handle transport encryption. They should only encrypt when it is opportune; encryption is not mandatory. To indicate the basic ability to encrypt to a sending server, it was agreed that the receiving server should send the keyword STARTTLS at the beginning of an ESMTP transport session. STARTTLS STARTTLS can encrypt the transport between two email servers. The receiving server signals the sending server that it is capable of encrypting after a connection is established and in the ESMTP session.
    [Show full text]
  • File Transfer Documentation
    LRS File Transfer Service Version 2 User Guide October 27, 2017 Introduction The LRS® File Transfer Service offers customers a secure way to send and receive files using HTTPS or FTPS protocols. This can help when working with LRS support staff, for example, in instances where you need to transmit files for troubleshooting or other support functions. The service supports the LRS Privacy Policy. If you want to read the LRS Privacy Policy, you can reach it from nearly any LRS web page. Just click the Online Privacy Policy link to read the complete company policy. You can also find the Privacy Policy at the following address: http://www.lrs.com/privacy-policy. This document explains the various file transfer options available and the steps required to send and/or receive files using the LRS File Transfer Service. Please refer to the following sections for more information about the system: File transfer options: HTTPS and FTPS 2 Sending a file to LRS via the File Transfer Service 3 Sending files via secured HTTPS 5 Sending files using FTP or secured FTPS 6 Receiving a file from the LRS File Transfer Service 8 File transfer options: HTTPS and FTPS Depending on the size of the file being transmitted, you may opt to use either the browser-based HTTPS protocol or the FTPS protocol, which requires the use of a file transfer client program. File sizes of up to 25GB can be transmitted via the secure HTTPS protocol using the LRS File Transfer Service. You can perform HTTPS-based transfers using most popular browsers, including Internet Explorer, Edge, Google Chrome, or Firefox.
    [Show full text]
  • Measuring the Rapid Growth of HSTS and HPKP Deployments
    Measuring the Rapid Growth of HSTS and HPKP Deployments Ivan Petrov∗ Denis Peskov∗ Gregory Coard∗ Taejoong Chungy David Choffnesy Dave Levin∗ Bruce M. Maggsz Alan Mislovey Christo Wilsony ∗ University of Maryland yNortheastern University zDuke University & Akamai Technologies ABSTRACT version of the website, thereby exposing future commu- A basic man-in-the-middle attack to bypass HTTPS strips nication to the MiTM attacker, as well. Second, if an the “s” off of an “https://” URL, thereby forcing the client attacker is able to have a certificate created in someone to effectively downgrade to an insecure connection. To ad- else's name, the attacker can impersonate that victim dress such crude attacks, the HSTS (HTTP Strict Transport domain. Security) protocol was recently introduced, which instructs Both of these attacks completely sidestep the protec- clients to preemptively (or at time of first acquire) load a tions that TLS seeks to provide to its users. To address list of domains to whom to connect strictly via HTTPS. In a these concerns, two recent additions to HTTPS have similar vein, the HPKP (HTTP Public Key Pinning) protocol been introduced. We describe them in detail in Sec- has clients obtain a set of public keys; if in future visits to tion 2, but at a high level: the website the certificate chain does not include any of those • HTTP Strict Transport Security public keys, the client is supposed to reject the connection. (HSTS) [10] addresses SSL stripping attacks by Both HSTS and HPKP are relatively new additions to the informing clients which domains it should connect web’s PKI that have seen a sudden surge in deployment in to strictly over HTTPS (i.e., if presented with an the last couple of years (we observe an order of magnitude http URL to one of these domains, they should greater deployment than a 2015 study of HSTS/HPKP).
    [Show full text]
  • MTA STS Improving Email Security.Pdf
    Improving Email Security with the MTA-STS Standard By Brian Godiksen An Email Best Practices Whitepaper CONTENTS Executive Overview 03 Why Does Email Need Encryption in Transit? 04 The Problem with “Opportunistic Encryption” 07 The Anatomy of a Man-in-the-Middle Attack 08 The Next Major Step with Email Encryption: MTA-STS 10 What Steps Should Senders Take to Adopt MTA-STS? 11 About SocketLabs 12 Brian Godiksen Brian has been helping organizations optimize email deliverability since joining SocketLabs in 2011. He currently manages a team of deliverability analysts that consult with customers on best infrastructure practices, including email authentication implementation, bounce processing, IP address warm-up, and email marketing list management. Brian leads the fight against spam and email abuse at SocketLabs by managing compliance across the platform. He is an active participant in key industry groups such as M3AAWG and the Email Experience Council. You can read more of Brian’s content here on the SocketLabs website. ©2019 SocketLabs 2 Executive The Edward Snowden leaks of 2013 opened many peoples’ eyes to the fact that mass surveillance was possible by Overview intercepting and spying on email transmissions. Today, compromised systems, database thefts, and technology breaches remain common fixtures in news feeds around the world. As a natural response, the technology industry is rabidly focused on improving the security and encryption of communications across all platforms. Since those early days of enlightenment, industry experts have discussed and attempted a variety of new strategies to combat “pervasive monitoring” of email channels. While pervasive monitoring assaults can take many forms, the most prominent forms of interference were man-in-the-middle (MitM) attacks.
    [Show full text]
  • Comptia Security+ 501
    CompTIA Security+ 501 CompTIA Security+ SY0-501 Instructor: Ron Woerner, CISSP, CISM CompTIA Security+ Domain 6 – Cryptography & PKI 6.4 Given a scenario, implement public key infrastructure Cybrary - Ron Woerner 1 CompTIA Security+ 501 6.4 Public-Key Infrastructure (PKI) ● Components ● Types of certificates ○ Public / Private Key ○ User ○ Certificate ○ Root ○ CA ○ Wildcard ○ CRL ○ SAN ○ Code signing ● Concepts ○ Self-signed ○ Online vs Offline CA ○ Machine/computer ○ Stapling ○ Domain validation ○ Pinning ○ Trust model ● Certificate formats ○ Key escrow ○ Certificate chaining Public and Private Keys ● Encrypt a document with the recipient’s public key. Only their private key needs to be kept secret and only it can decrypt the message ● The sender’s private key is used to sign the message Cybrary - Ron Woerner 2 CompTIA Security+ 501 PKI Components Public Key Infrastructure ● Solves the issues with key management ● A set of roles, policies, and procedures needed to manage public- key(asymmetric) encryption ● The process of creating, managing, distributing, storing, using, and revoke keys and digital certificates. ● Public Key Infrastructure X.509 (PKIX) is the working group formed by the IETF to develop standards and models PKI PKI Components - Digital Certificate ● A digitally signed block of data used to prove the ownership of a public key issued by a Certificate Authority ● Includes ○ information about the key, ○ information about the identity of its owner (called the subject), ○ and the digital signature of an entity that has verified the certificate's contents (called the issuer) ● X.509 v3 standard defines the certificate formats and fields for public keys. Cybrary - Ron Woerner 3 CompTIA Security+ 501 Digital Certificate Components X.509 Certificate Types ● Root certificates: for root authorities.
    [Show full text]
  • Curl User Survey 2019 Analysis
    curl user survey 2019 analysis “there are so many useful features” summary and analysis by Daniel Stenberg version 1 - June 4, 2019 Table of Contents About curl.............................................................................................................................................3 Survey Background..........................................................................................................................3 Number of responses............................................................................................................................4 Returning respondents?........................................................................................................................5 Users living where?..............................................................................................................................6 What kind of users?..............................................................................................................................7 What protocols......................................................................................................................................8 Multiple platforms..............................................................................................................................10 What platforms...................................................................................................................................11 Which Windows versions...................................................................................................................13
    [Show full text]
  • Technical Report RHUL–ISG–2019–1 27 March 2019
    20 years of Bleichenbacher attacks Gage Boyle Technical Report RHUL–ISG–2019–1 27 March 2019 Information Security Group Royal Holloway University of London Egham, Surrey, TW20 0EX United Kingdom Student Number: 100866673 Gage, Boyle 20 Years of Bleichenbacher Attacks Supervisor: Kenny Paterson Submitted as part of the requirements for the award of the MSc in Information Security at Royal Holloway, University of London. I declare that this assignment is all my own work and that I have acknowledged all quotations from published or unpublished work of other people. I also declare that I have read the statements on plagiarism in Section 1 of the Regulations Governing Examination and Assessment Offences, and in accordance with these regulations I submit this project report as my own work. Signature: Date: Acknowledgements I would first like to thank my project supervisor, Kenny Paterson. This project would not have been possible without his continuous encouragement to push the boundaries of my knowledge, and I am grateful for the commitment and expertise that he has provided throughout. Secondly, I would like to thank Nimrod Aviram for his invaluable advice, particularly with respect to algorithm implementation and understanding the finer details of this project. Further thanks should go to Raja Naeem Akram, Oliver Kunz and David Morrison for taking the time to teach me Python and how to run my source code on an Ubuntu server. I am grateful for the time that David Stranack, Thomas Bingham and James Boyle have spent proof reading this project, and for the continuous support from my part- ner, Lisa Moxham.
    [Show full text]
  • TLS Deep Dive
    12/9/17 TLS Deep Dive Website Security & More Joe Pranevich December 5, 2017 Today’s Session – Overview of TLS – Connection Establishment – Testing Tools – Recent Security Issues 1 12/9/17 What is SSL/TLS? – Core internet protocols (IP, TCP, HTTP) were designed without default security – SSL was invented in 1995 by Netscape to support encryption of web traffic for ecommerce and other uses. – SSL/TLS sits above TCP. It can be used to encrypt many protocols, but mostly used for HTTP. – Over two decades, SSL has been improved (with vulnerabilities discovered in older versions). The name was changed to TLS in 1999. SSL & TLS Timeline Protocol Released Notes SSLv2 1995 Vulnerable, depreciated in 2011 SSLv3 1996 Vulnerable, depreciated in 2015 TLS 1.0 1999 At risk, no longer permitted by PCI TLS 1.1 2006 TLS 1.2 2008 TLS 1.3 TBD Internet Draft 2 12/9/17 But Wait, There’s More! – TLS supports dozens of different encryption methods, compression methods, hashing functions, and other details. – Clients and servers select from a menu of these options to negotiate the best security (more on that later) – Most of these options have their own security histories, some have been deprecated, etc. Key Concepts – Shared Key Cryptography (Symmertric) – Public/Private Key Cryptography (Asymmetric) – Hashing 3 12/9/17 Connection Establishment – TLS Handshake – Cipher negotiation – Certificate Validation – Device Compatibility TLS Handshake – Part One – Client sends a “hello” message saying that they want TLS. – It includes TLS version, ciphers it supports, and other details – Server sends a “hello” message back. – It selects the most secure matching TLS version and ciphers – Connection will fail if client and server cannot agree on protocols and ciphers 4 12/9/17 Client Devices Have Different Capabilities As Do Servers & Load Balancers 5 12/9/17 We Care About The Intersection Backwards Compatibility Warning! – Web browsers and operating systems get updated frequently; you can usually rely on web users having a recent TLS stack when they connect to you.
    [Show full text]
  • 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.
    [Show full text]
  • Ftp Vs Http Protocol
    Ftp Vs Http Protocol Unilobed Bentley unstrings reportedly while Durand always waul his stigmatists lull remittently, he dozing so asymmetrically. When Stuart ad-lib his ageings bumble not centrically enough, is Bryant definite? Jerold often appraised wearily when corruptible Tomlin blackouts balefully and expiate her Libyan. FTP stands for File Transfer Protocol used to transfer files online. To ensure the functionality of the Sophos Web Appliance, configure your network to allow access on the ports listed below. Syntax error in any data since a time when and passive mode, when a tcp connection and get closed prematurely or http or other end the parent directory. What is File Transfer Protocol FTP What she My IP Address. Why FTPFTPSSFTP file transport related protocols are not mentioned but used HTTPS As did general concepts PUTGET are more FTP related requests. Using ftp protocol relatively easy to the protocols can just serve other. The ftp vs protocol, not to the protocol. Expand your ftp vs https protocols offer the size can use in the server needs to the latest version. This ftp vs http is specifically remember the protocols with ftps: it is not at once authenticated and services similar. Rfcs are ftp protocol at this https protocols in the ass with. Smtp server ftp protocol runs on http does it has rules to https because data packets are on. To begin a characterbased command session on a Windows computer, follow these steps. The web server sends the requested content really a response message. XML and JSON and learned that kid are custom data formats indeed.
    [Show full text]