DOCSLIB.ORG

TLS Decryption on Cisco Security Devices

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
TLS Decryption on Cisco Security Devices BRKSEC-3015 TLS Decryption on Cisco Security Devices Tobias Mayer, Technical Solutions Architect Cisco Spark Questions? Use Cisco Spark to communicate with the speaker after the session How 1. Find this session in the Cisco Live Mobile App 2. Click “Join the Discussion” 3. Install Spark or go directly to the space 4. Enter messages/questions in the space cs.co/ciscolivebot#BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public Abstract This advanced session will discuss the approach how we can decrypt TLS encrypted web traffic to be able to inspect it and what challenges we are facing in an enterprise environment. For this, we need to be able to understand how TLS is working and what is required to decrypt this traffic.The second section will then include some best practices for Cisco security products dealing with TLS decryption such as Firepower, WSA and Umbrella. The last part will give an introduction to encrypted protocols such as HTTP/2, TLS 1.3 and QUIC. Those protocols are making it harder to decrypt certain traffic flows and we need to think about complementing technologies that still enforce security in the network. As additional food for thought we will quickly also touch on OCSP Stapling and Google's Certificate Transparency, which are interesting additions to the TLS landscape.This session is intended for network and security architects that want to get a deeper understanding of decryption of web traffic in the enterprise. Attendees should be familiar with the overall concept of HTTP, HTTPS and TLS. BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 4 Me… CCIE Security #14390, CISSP & Motorboat driving license… Working in Content Security & TLS Security tmayer{at}cisco.com Writing stuff at “blogs.cisco.com” BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 5 “Hey, I am going to present on Web Decryption for 2 hours!” BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 6 Agenda • Introduction • Understanding TLS • Configuring Decryption on the WSA • Configuring Decryption on Cisco Firepower • Configuring Decryption on Umbrella • Thoughts about the future • Certificate Transparency & OCSP Stapling • HTTP/2 , TLS 1.3 & QUIC For Your Reference • There are (many...) slides in your print-outs that will not be presented. • They are there “For your Reference” For Your Reference BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 8 Big push for encryption • Microsoft pushing TLS with PFS • Apple demanding transport security • Browser Vendors aggressively pushing https • Problems with older TLS versions leading to upgrade of servers to newer protocols and ciphers • Poodle, Freak, Beast, …. • Google, FB, Twitter encrypting all traffic • HTTPS usage influencing page ranking on google • Deprecate SHA1, only SHA2+ BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 9 Google Search Engine • Google ranking influenced by using HTTPS • http://blog.searchmetrics.com/us/2015/ 03/03/https-vs-http-website-ssl-tls- encryption-ranking-seo-secure- connection/ BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 10 Understanding TLS TLS Versions • SSLv3, 1996 • TLS 1.0, 1999, RFC2246 • TLS 1.1, 2006, RFC4346 • Improved security • TLS 1.2, 2008, RFC5246 • Removed IDEA and DES ciphers • Stronger hashes • Supports authenticated encryption ciphers (AES-GCM) • TLS 1.3, currently Internet Draft BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 12 Some Attacks… • POODLE • SSLv3 Problems with Padding, turn of SSLv3 • BEAST • Know issues in CBC mode, use TLS 1.1/1.2 with non-CBC mode ciphers (GCM) • CRIME/BREACH • Compression Data Leak, disable compression in TLS (CRIME), HTTP Compression still there • Lucky13 • Problem with Padding still exists with CBC Ciphers, use TLS 1.2 with AEAD (GCM) • Freak • Downgrade to RSA_EXPORT, disable EXPORT CIPHERS, use TLS 1.2 • Logjam • Force client to downgrade to DHE_EXPORT Grade ciphers, disable DHE_EXPORT Ciphers, use TLS 1.2 BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 13 TLS Versions • SSLv3, 1996, broken by Poodle • TLS 1.0, 1999, RFC2246, weakend by BEAST & Lucky13 • TLS 1.1, 2006, RFC4346, weakend by Lucky13 • Improved security • TLS 1.2, 2008, RFC5246 • Removed IDEA and DES ciphers • Stronger hashes • Supports authenticated encryption ciphers (AEAD, i.e. AES-GCM) • TLS 1.3, currently Internet Draft BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 14 How is the encryption of the target website? BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 15 Cipherstrings Protocol used Key Exchange Authentication TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 Symmetric Encryption Hash to verify integrity used BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 16 Old and modern ciphers old modern Protocol SSL TLS Key exchange RSA EC(DHE) * Authentication RSA EC(DSA) Encryption 3DES, RC4 AES algorithm Encryption mode CBC GCM MAC SHA, MD5 SHA256,SHA368 * Ephemeral DH provides PFS BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 17 PFS – Perfect Forward Secrecy • Using RSA key for authentication and key generation is putting our traffic vulnerable to offline attacks • Someone might record out traffic and years later, compromise our Server, get the private key and decrypt all traffic. • Diffie-Hellman (DH) is a method to prevent this, but: • With static DH, the DH parameters are actually again the private key… • DHE is using unique keys for every session, this is called Perfect Forward Secrecy • Dynamic parameters for the DH Session are never stored and never re-used BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 18 PFS - Example • DHE Ciphers use PFS • But are heavy to compute… • ECDHE Ciphers use Ecliptic Curves and provide PFS • Much better performance • Especially in Software BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 19 AEAD – Authenticated Encryption https://en.wikipedia.org/wiki/Authenticated_encryption • Authenticated Encryption with associated data • CBC (confidentiality) + HMAC(integrity) vs. AE(confidentiality & integrity) • GCM is the most popular Algorithm https://en.wikipedia.org/wiki/Galois/Counter_Mode • No License and fast computing • Implemented in OPENSSL BRKSEC-3005 Cryptographic Protocols and Algorithms - a review BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 20 AEAD – Authenticated Encryption (2) https://www.imperialviolet.org/2015/05/16/aeads.html • AE (key, plaintext) -> Ciphertext • Same plaintext letter results in same ciphertext letter (“hello” -> “&%$$”) • AE (key, plaintext, nonce) -> Ciphertext • Nonce needs to be distinct! • Need to send it along with the ciphertext • Problem: order of the messages! • AEAD (key, plaintext, nonce, ad) -> Ciphertext • “ad” is the associated data, can be a counter. • RULE: The combination of “nonce” and “ad” shall never be the same for all time! BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 21 Ciphers explained Name Prot Kx Au Enc Bits Mac TLS_RSA_WITH_RC4_128_MD5 TLS RSA RSA RC4_128 128 MD5 TLS_DH_RSA_WITH_DES_CBC_SHA TLS DH RSA DES_CBC 56 SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS DHE RSA AES_128_CBC 128 SHA TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS ECDH ECDSA AES_256_CBC 256 SHA TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS ECDHE RSA AES_256_GCM 256 SHA384 BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 22 Ciphers explained (2) • TLS_EMPTY_RENEGOTIATION_INFO_SCSV Cipher is sent to indicate that if the server wishes to renegotiate any parameters, this is only supported over the secure connection. Renegotiation over plaintext will not be accepted • TLS_FALLBACK_SCSV Cipher is sent by the client when a previous connection with a higher protocol was not successful for whatever reason (TLS 1.2 -> TLS 1.0) Server who supports this cipher can now see that the session was “downgraded” BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 23 TLS Handshake Client Server BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 24 TLS Handshake Client Server ClientHello BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 25 TLS Handshake Client Server ClientHello ServerHello BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 26 TLS Handshake Client Server ClientHello ServerHello ServerCertChain & (SrvKeyExchg) BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 27 TLS Handshake Client Server ClientHello ServerHello ServerCertChain & (SrvKeyExchg) Verify Server Certificate & Check Crypto Parameters BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 28 TLS Handshake Client Server ClientHello ServerHello ServerCertChain & (SrvKeyExchg) Verify Server Certificate & ClientKeyExch Check Crypto Parameters BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved. Cisco Public 29 TLS Handshake Client Server ClientHello ServerHello ServerCertChain & (SrvKeyExchg) Verify Server Certificate & ClientKeyExch Check Crypto Parameters ChangeCipherSpec ClientFinished BRKSEC-3015 © 2018 Cisco and/or its affiliates. All rights reserved.
Load more

Recommended publications
  • SSL/TLS Implementation CIO-IT Security-14-69
    DocuSign Envelope ID: BE043513-5C38-4412-A2D5-93679CF7A69A IT Security Procedural Guide: SSL/TLS Implementation CIO-IT Security-14-69 Revision 6 April 6, 2021 Office of the Chief Information Security Officer DocuSign Envelope ID: BE043513-5C38-4412-A2D5-93679CF7A69A CIO-IT Security-14-69, Revision 6 SSL/TLS Implementation VERSION HISTORY/CHANGE RECORD Person Page Change Posting Change Reason for Change Number of Number Change Change Initial Version – December 24, 2014 N/A ISE New guide created Revision 1 – March 15, 2016 1 Salamon Administrative updates to Clarify relationship between this 2-4 align/reference to the current guide and CIO-IT Security-09-43 version of the GSA IT Security Policy and to CIO-IT Security-09-43, IT Security Procedural Guide: Key Management 2 Berlas / Updated recommendation for Clarification of requirements 7 Salamon obtaining and using certificates 3 Salamon Integrated with OMB M-15-13 and New OMB Policy 9 related TLS implementation guidance 4 Berlas / Updates to clarify TLS protocol Clarification of guidance 11-12 Salamon recommendations 5 Berlas / Updated based on stakeholder Stakeholder review / input Throughout Salamon review / input 6 Klemens/ Formatting, editing, review revisions Update to current format and Throughout Cozart- style Ramos Revision 2 – October 11, 2016 1 Berlas / Allow use of TLS 1.0 for certain Clarification of guidance Throughout Salamon server through June 2018 Revision 3 – April 30, 2018 1 Berlas / Remove RSA ciphers from approved ROBOT vulnerability affected 4-6 Salamon cipher stack
    [Show full text]
  • 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”
    [Show full text]
  • Quantitative Verification of Gossip Protocols for Certificate Transparency
    QUANTITATIVE VERIFICATION OF GOSSIP PROTOCOLS FOR CERTIFICATE TRANSPARENCY by MICHAEL COLIN OXFORD A thesis submitted to the University of Birmingham for the degree of DOCTOR OF PHILOSOPHY School of Computer Science College of Engineering and Physical Sciences University of Birmingham December 2020 2 Abstract Certificate transparency is a promising solution to publicly auditing Internet certificates. However, there is the potential of split-world attacks, where users are directed to fake versions of the log where they may accept fraudulent certificates. To ensure users are seeing the same version of a log, gossip protocols have been designed where users share and verify log-generated data. This thesis proposes a methodology of evaluating such protocols using probabilistic model checking, a collection of techniques for formally verifying properties of stochastic systems. It also describes the approach to modelling and verifying the protocols and analysing several aspects, including the success rate of detecting inconsistencies in gossip messages and its efficiency in terms of bandwidth. This thesis also compares different protocol variants and suggests ways to augment the protocol to improve performances, using model checking to verify the claims. To address uncertainty and unscalability issues within the models, this thesis shows how to transform models by allowing the probability of certain events to lie within a range of values, and abstract them to make the verification process more efficient. Lastly, by parameterising the models, this thesis shows how to search possible model configurations to find the worst-case behaviour for certain formal properties. 4 Acknowledgements To Auntie Mary and Nanny Lee. Writing this thesis could not have been accomplished after four tumultuous years alone.
    [Show full text]
  • 1. Ipv4 Sites Reaching Global Ipv4 Internet
    1. IPv4 Sites Reaching Global IPv4 Internet Private IPv4 Internet IPv4 NAT • Keep IPv4 service as unchanged as possible, even without enough addresses • Single global IPv4 address shared across more than one subscriber SP IPv6 Network Private Tunnel for IPv4 (public, private, port-limited, etc....) IPv4 Internet IPv4 • Scenario #2 - Service Providers Running out of Private IPv4 space • IPv4 / IPv6 encapsulations/tunnels • Tunnels setup by DHCP, Routing, etc. between a GW and Router • Wherever the NAT lands, it is important that the user keeps control of it • Provides a path to delivering IPv6 SP IPv6 Network Tunnel for IPv4 (public, private, port-limited, etc....) IPv4 Internet • Scenario #3a “Wireless Greenfield” • IPv4 / IPv6 encapsulations/tunnels • Tunnels setup between a host and a Router • IPv4 binding for host applications, transport over IPv6 • Wherever the NAT lands, it is important that the user keeps control of it 3 - 5 Translation Options IPv6 Internet IPv4 Internet IPv6 IPv4 My IPv6 Network IPv6 Internet IPv4 Internet • “Scenario #3” • NAT64/DNS64.... - Stateful, DNSSEC Challenges, DNS64 location, etc. My IPv6 Network IPv6 Internet IPv4 Internet • “Scenario #5” • IVI - NAT-PT..... Expose only certain IPv6 servers, etc. MY IPv4 Network IPv6 Internet IPv4 Internet • “Scenario #4” • NAT64 - 1:1, Stateless, DNSSEC OK, no DNS64 MY IPv4 Network IPv6 Internet IPv4 Internet • Already solved by existing transition mechanisms?? (teredo, etc). Scenarios 1 - 5 1. IPv4 Sites Reaching Global IPv4 Internet Private IPv4 Internet IPv4 NAT • Keep IPv4 service as unchanged as possible, even without enough addresses • Single global IPv4 address shared across more than one subscriber 2. Service Providers Running out of Private IPv4 space ISP Private IPv4 Private Network IPv4 IPv4 Internet • Service Providers with large, privately addressed, IPv4 networks • Organic growth plus pressure to free global addresses for customer use contribute to the problem • The SP Private networks in question generally do not need to reach the Internet at large 3.
    [Show full text]
  • Is QUIC a Better Choice Than TCP in the 5G Core Network Service Based Architecture?
    DEGREE PROJECT IN INFORMATION AND COMMUNICATION TECHNOLOGY, SECOND CYCLE, 30 CREDITS STOCKHOLM, SWEDEN 2020 Is QUIC a Better Choice than TCP in the 5G Core Network Service Based Architecture? PETHRUS GÄRDBORN KTH ROYAL INSTITUTE OF TECHNOLOGY SCHOOL OF ELECTRICAL ENGINEERING AND COMPUTER SCIENCE Is QUIC a Better Choice than TCP in the 5G Core Network Service Based Architecture? PETHRUS GÄRDBORN Master in Communication Systems Date: November 22, 2020 Supervisor at KTH: Marco Chiesa Supervisor at Ericsson: Zaheduzzaman Sarker Examiner: Peter Sjödin School of Electrical Engineering and Computer Science Host company: Ericsson AB Swedish title: Är QUIC ett bättre val än TCP i 5G Core Network Service Based Architecture? iii Abstract The development of the 5G Cellular Network required a new 5G Core Network and has put higher requirements on its protocol stack. For decades, TCP has been the transport protocol of choice on the Internet. In recent years, major Internet players such as Google, Facebook and CloudFlare have opted to use the new QUIC transport protocol. The design assumptions of the Internet (best-effort delivery) differs from those of the Core Network. The aim of this study is to investigate whether QUIC’s benefits on the Internet will translate to the 5G Core Network Service Based Architecture. A testbed was set up to emulate traffic patterns between Network Functions. The results show that QUIC reduces average request latency to half of that of TCP, for a majority of cases, and doubles the throughput even under optimal network conditions with no packet loss and low (20 ms) RTT. Additionally, by measuring request start and end times “on the wire”, without taking into account QUIC’s shorter connection establishment, we believe the results indicate QUIC’s suitability also under the long-lived (standing) connection model.
    [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]
  • Internet Protocol Suite
    InternetInternet ProtocolProtocol SuiteSuite Srinidhi Varadarajan InternetInternet ProtocolProtocol Suite:Suite: TransportTransport • TCP: Transmission Control Protocol • Byte stream transfer • Reliable, connection-oriented service • Point-to-point (one-to-one) service only • UDP: User Datagram Protocol • Unreliable (“best effort”) datagram service • Point-to-point, multicast (one-to-many), and • broadcast (one-to-all) InternetInternet ProtocolProtocol Suite:Suite: NetworkNetwork z IP: Internet Protocol – Unreliable service – Performs routing – Supported by routing protocols, • e.g. RIP, IS-IS, • OSPF, IGP, and BGP z ICMP: Internet Control Message Protocol – Used by IP (primarily) to exchange error and control messages with other nodes z IGMP: Internet Group Management Protocol – Used for controlling multicast (one-to-many transmission) for UDP datagrams InternetInternet ProtocolProtocol Suite:Suite: DataData LinkLink z ARP: Address Resolution Protocol – Translates from an IP (network) address to a network interface (hardware) address, e.g. IP address-to-Ethernet address or IP address-to- FDDI address z RARP: Reverse Address Resolution Protocol – Translates from a network interface (hardware) address to an IP (network) address AddressAddress ResolutionResolution ProtocolProtocol (ARP)(ARP) ARP Query What is the Ethernet Address of 130.245.20.2 Ethernet ARP Response IP Source 0A:03:23:65:09:FB IP Destination IP: 130.245.20.1 IP: 130.245.20.2 Ethernet: 0A:03:21:60:09:FA Ethernet: 0A:03:23:65:09:FB z Maps IP addresses to Ethernet Addresses
    [Show full text]
  • 26. Java 8 and 8 Security Controls 2-28-2017
    New Security Control Enhancements Java 8 and 9 JIM MANICO Secure Coding Instructor www.manicode.com A little background dirt… [email protected] @manicode § Author of "Iron-Clad Java, Building Secure Web APPlications” from McGraw-Hill/Oracle-Press § 20+ years of software develoPment experience § OWASP Volunteer and Former OWASP Global Board Member § Kauai, Hawaii Resident Creative Commons MANICODE SECURITY 2 Java Enhancement ProPosals Creative Commons MANICODE SECURITY 3 'ohana (oh-ha-na) MEANING: Family. MOST COMMON USE: In referring to the WHOLE family. Creative Commons MANICODE SECURITY JEP IT UP § JEP stands for a JDK Enhancement Proposal § JEP's are how you drive change in the Java ecosystem. § Involvement is actually a lot of work. § Attention is given to PeoPle that put in the work. § The way to make imProvements or get ideas seriously considered is to do them via the JEP ProPosal Process. § Mike Ernst and Werner Dietl are good examPles. They are the duo that built type annotations which we we will talk about soon. Creative Commons MANICODE SECURITY 5 Java 9 Security JEP's Creative Commons MANICODE SECURITY 6 Java 9 Security Enhancements § There are 8 main security related JEPs for JDK 9: 219: Datagram Transport Layer Security (DTLS) 229: Create PKCS12 Keystores by Default 232: ImProve Secure APPlication Performance 244: TLS Application-Layer Protocol Negotiation Extension 246: Leverage CPU Instructions for GHASH and RSA 249: OCSP Stapling for TLS 287: Support SHA-3 Hash Algorithms 288: DisaBle SHA-1 Certificates Creative Commons MANICODE SECURITY 7 akamai (ah-ka-my) MEANING: Smart or Clever. MOST COMMON USE: Smart.
    [Show full text]
  • The Internet Protocol, Version 4 (Ipv4)
    Today’s Lecture I. IPv4 Overview The Internet Protocol, II. IP Fragmentation and Reassembly Version 4 (IPv4) III. IP and Routing IV. IPv4 Options Internet Protocols CSC / ECE 573 Fall, 2005 N.C. State University copyright 2005 Douglas S. Reeves 1 copyright 2005 Douglas S. Reeves 2 Internet Protocol v4 (RFC791) Functions • A universal intermediate layer • Routing IPv4 Overview • Fragmentation and reassembly copyright 2005 Douglas S. Reeves 3 copyright 2005 Douglas S. Reeves 4 “IP over Everything, Everything Over IP” IP = Basic Delivery Service • Everything over IP • IP over everything • Connectionless delivery simplifies router design – TCP, UDP – Dialup and operation – Appletalk – ISDN – Netbios • Unreliable, best-effort delivery. Packets may be… – SCSI – X.25 – ATM – Ethernet – lost (discarded) – X.25 – Wi-Fi – duplicated – SNA – FDDI – reordered – Sonet – ATM – Fibre Channel – Sonet – and/or corrupted – Frame Relay… – … – Remote Direct Memory Access – Ethernet • Even IP over IP! copyright 2005 Douglas S. Reeves 5 copyright 2005 Douglas S. Reeves 6 1 IPv4 Datagram Format IPv4 Header Contents 0 4 8 16 31 •Version (4 bits) header type of service • Functions version total length (in bytes) length (x4) prec | D T R C 0 •Header Length x4 (4) flags identification fragment offset (x8) 1. universal 0 DF MF s •Type of Service (8) e time-to-live (next) protocol t intermediate layer header checksum y b (hop count) identifier •Total Length (16) 0 2 2. routing source IP address •Identification (16) 3. fragmentation and destination IP address reassembly •Flags (3) s •Fragment Offset ×8 (13) e t 4. Options y IP options (if any) b •Time-to-Live (8) 0 4 ≤ •Protocol Identifier (8) s e t •Header Checksum (16) y b payload 5 •Source IP Address (32) 1 5 5 6 •Destination IP Address (32) ≤ •IP Options (≤ 320) copyright 2005 Douglas S.
    [Show full text]
  • Let's Encrypt: 30,229 Jan, 2018 | Let's Encrypt: 18,326 Jan, 2016 | Let's Encrypt: 330 Feb, 2017 | Let's Encrypt: 8,199
    Let’s Encrypt: An Automated Certificate Authority to Encrypt the Entire Web Josh Aas∗ Richard Barnes∗ Benton Case Let’s Encrypt Cisco Stanford University Zakir Durumeric Peter Eckersley∗ Alan Flores-López Stanford University Electronic Frontier Foundation Stanford University J. Alex Halderman∗† Jacob Hoffman-Andrews∗ James Kasten∗ University of Michigan Electronic Frontier Foundation University of Michigan Eric Rescorla∗ Seth Schoen∗ Brad Warren∗ Mozilla Electronic Frontier Foundation Electronic Frontier Foundation ABSTRACT 1 INTRODUCTION Let’s Encrypt is a free, open, and automated HTTPS certificate au- HTTPS [78] is the cryptographic foundation of the Web, providing thority (CA) created to advance HTTPS adoption to the entire Web. an encrypted and authenticated form of HTTP over the TLS trans- Since its launch in late 2015, Let’s Encrypt has grown to become the port [79]. When HTTPS was introduced by Netscape twenty-five world’s largest HTTPS CA, accounting for more currently valid cer- years ago [51], the primary use cases were protecting financial tificates than all other browser-trusted CAs combined. By January transactions and login credentials, but users today face a growing 2019, it had issued over 538 million certificates for 223 million do- range of threats from hostile networks—including mass surveil- main names. We describe how we built Let’s Encrypt, including the lance and censorship by governments [99, 106], consumer profiling architecture of the CA software system (Boulder) and the structure and ad injection by ISPs [30, 95], and insertion of malicious code of the organization that operates it (ISRG), and we discuss lessons by network devices [68]—which make HTTPS important for prac- learned from the experience.
    [Show full text]
  • Analysis of QUIC Session Establishment and Its Implementations Eva Gagliardi, Olivier Levillain
    Analysis of QUIC session establishment and its implementations Eva Gagliardi, Olivier Levillain To cite this version: Eva Gagliardi, Olivier Levillain. Analysis of QUIC session establishment and its implementations. 13th IFIP International Conference on Information Security Theory and Practice (WISTP), Dec 2019, Paris, France. pp.169-184, 10.1007/978-3-030-41702-4_11. hal-02468596 HAL Id: hal-02468596 https://hal.archives-ouvertes.fr/hal-02468596 Submitted on 5 Feb 2020 HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. Analysis of QUIC Session Establishment and its Implementations Eva Gagliardi1 and Olivier Levillain2 1 French Ministry of the Armies, 2 T´el´ecomSudParis, Institut Polytechnique de Paris Abstract. In the recent years, the major web companies have been working to improve the user experience and to secure the communica- tions between their users and the services they provide. QUIC is such an initiative, and it is currently being designed by the IETF. In a nutshell, QUIC originally intended to merge features from TCP/SCTP, TLS 1.3 and HTTP/2 into one big protocol. The current specification proposes a more modular definition, where each feature (transport, cryptography, application, packet reemission) are defined in separate internet drafts.
    [Show full text]
  • X.509V3 Certificates for SSH Authentication
    X.509v3 Certificates for SSH Authentication The X.509v3 Certificates for SSH Authentication feature uses public key algorithm (PKI) for server and user authentication, and allows the Secure Shell (SSH) protocol to verify the identity of the owner of a key pair via digital certificates, signed and issued by a Certificate Authority (CA). This module describes how to configure server and user certificate profiles for a digital certificate. • Prerequisites for X.509v3 Certificates for SSH Authentication, on page 1 • Restrictions for X.509v3 Certificates for SSH Authentication, on page 1 • Information About X.509v3 Certificates for SSH Authentication, on page 2 • How to Configure X.509v3 Certificates for SSH Authentication, on page 3 • Verifying the Server and User Authentication Using Digital Certificates , on page 6 • Configuration Examples for X.509v3 Certificates for SSH Authentication, on page 6 • Additional References for X.509v3 Certificates for SSH Authentication, on page 7 • Feature Information for X.509v3 Certificates for SSH Authentication, on page 8 Prerequisites for X.509v3 Certificates for SSH Authentication The X.509v3 Certificates for SSH Authentication feature replaces the ip ssh server authenticate user command with the ip ssh server algorithm authentication command. Configure the default ip ssh server authenticate user command to remove the ip ssh server authenticate user command from the configuration. The IOS secure shell (SSH) server will start using the ip ssh server algorithm authentication command. When you configure the ip ssh server authenticate user command, the following message is displayed: Warning SSH command accepted; but this CLI will be deprecated soon. Please move to new CLI ip ssh server algorithm authentication.
    [Show full text]