HTTPandSecureChannel
2
IP IP
TCPTCP
HTTP TLS
HTTP
SSL/TLS• SSL and TLS
– SSL v3.0 specified in an I-D in 1996 (draft-freier-ssl-version3-02.txt) and now in RFC6101
– TLS v1.0 specified in RFC2246• TLS v1.0 = SSL v3.1 ≈ SSL v3.0
– TLS v1.1 specified in RFC4346– TLS v1.2 specified in RFC5246
• Goals of protocol– Secure communication between applications– Data encryption– Server authentication– Message integrity– Client authentication (optional)
3
SSLisnotsecureanymore
• SSL2.0andSSL3.0haveknownvulnerabilitiesinprotocolspecifications– downgradeattack– POODLEattack– RFC6176- ProhibitingSecureSocketsLayer(SSL)Version2.0
– RFC7568- DeprecatingSecureSocketsLayerVersion3.0
• UseTLSinstead
4
TLSProperties• Connection is private
– Encryption is used after an initial handshake to define a secret key.
– Symmetric cryptography used for data encryption • Peer’s identity can be authenticated
– Asymmetric cryptography is used (RSA or ECDSA) • Connection is reliable
– Message transport includes a message integrity check using a keyed MAC.
– Secure hash functions (such as SHA384, SHA256) are used for MAC computations.
5
6
TheTLSHandshakeProcess
Internet
TLS Client TLS Server
Client initiates TLS connection / sends supported cipher suites
Server returns digital certificate to client and selected cipher suite
Client sends shared secret encrypted with server’s public key
Message encryption and integrity algorithms are negotiated
Secure session tunnel is established
Session keys are generated
1
6
5
4
3
2
7
TLSClientAuthentication
- Clientauthentication(certificatebased)isoptionalandnotoftenused
- Manyapplicationprotocolsincorporatetheirownclientauthenticationmechanismsuchasusername/passwordorS/Key
- TheseauthenticationmechanismsaremoresecurewhenrunoverTLS
8
TLSIANAAssignedPort#s
Protocol Defined Port Number
TLS Port Number
HTTP 80 443NNTP 119 563POP 110 995FTP-Data 20 989FTP-Control 21 990Telnet 23 992
TLSpolicyexample• ServerKey
– RSA2048bitormore– ECDSA256bitormore
• Protocols– enableTLS1.2,TLS1.1,TLS1.0anddisableSSL
• CiphersSuites– TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
• 1024bitormorekeylength– TLS_RSA_WITH_AES_128_GCM_SHA256– TLS_RSA_WITH_AES_128_CBC_SHA
• 2048bitormorekeylength
9
CertificateAuthority
• IssuesadigitalcertificatewhichissignedbytheCA’sprivatekey
• Youcanverifythecertificateusingthecorrespondingpublickey– ifyoutrustthepublickey
• …andCAcanhavehierarchicaltrustmodel
10
Trustchain
11
rootCA
intermidiateCA
endentitycert
sign
sign
endentitycert
sign
https://www.apricot.net
12
trustedCA
13
CAandcertificates
• CAcanissueacertificateforanydomainname– ifyoutrusttheCA,thecertificatelookslegitimate
• ifyouhaveamaliciousCAinyourtrustedkeychain,anattackercanmonitor/modifyyourTLSsessiondata
• Yes,wehavecases– https://support.lenovo.com/nz/en/product_security/superfish
– https://www.dell.com/support/article/us/en/19/SLN300321
14
CheckyourtrustedCA
• Windows– certlm.msc
• MacOSX– KeychainAccess.app
• Firefox– Setting->Advanced->Certificates->
ViewCertificates
15
VPN
16
VirtualPrivateNetwork
• OverlayNetwork– aVPNisbuiltontopofapublicnetwork(Internet)
• Costeffective– Youdon’tneedtoexpandyournetwork
• Rapidlydeployable– AnunderlaynetworkjustcarriesIPpacketsasusual– OnlyyournodesneedtoagreeaboutVPN
• Control– YoucanenforceyourownpolicyintheVPN
17
satelliteoffice
18
accesstointranetfromoutside
19
overanuntrustednetwork
20
IPv4andIPv6• pathtogetadestination• cacheDNS
21
VPN andsecurity
• AnyVPNisnot automagically secure.YouneedtoaddsecurityfunctionalitytocreatesecureVPNs.ThatmeansusingfirewallsforaccesscontrolandprobablyIPsec orSSL/TLSforconfidentialityanddataoriginauthentication.
22
VPNprotocols• PPTP
– IPoverPPPoverGRE– possiblepasswordleakagebyMS-CHAPv2weakness
• OpenVPN– IPoverTLSoverTCP/UDP
• MS-SSTP– IPoverPPPoverSSTPoverHTTPSoverTCP
• L2TP/IPsec– IPoverPPPoverL2TPoverUDPoverESP
• IPsec– IPoverESP– IPoverESPoverUDP(NATtraversal)
23
24
Layer2TunnelingProtocol
- Designed in IETF PPP Extensions working group- Combination of Cisco L2F & PPTP features- L2TP RFC 2661, Aug 1999- Uses UDP port 1701 for control and data packets- Uses PPP for packet encapsulation – carries most
protocols (also non-IP protocols)- Security Functionality
- Control session authentication, keepalives- EAP for a broader authentication mechanisms- IPsec ESP for confidentiality and integrity - IKE for key management
25
L2TPandIPsec
TCPUDP Application DataUDPIP IPIPSEC
(ESP) L2TP PPP IPSEC(ESP Trailer)
IPsec encrypted
Multiple Encapsulations…..careful of packet size!!
Ping with large MTU size….help discover fragmentation issues!!
IPSec
Internet
WhatIsIPSec?
• IETFstandardthatenablesencryptedcommunicationbetweenpeers:– Consistsofopenstandardsforsecuringprivatecommunications– Networklayerencryptionensuringdataconfidentiality,integrity,
andauthentication– Scalesfromsmalltoverylargenetworks
26
27
WhatDoesIPsecProvide?• Confidentiality….manyalgorithmstochoosefrom• Dataintegrityandsourceauthentication
– Data“signed”bysenderand“signature”verifiedbytherecipient– Modificationofdatacanbedetectedbysignature“verification”– Because“signature”basedonasharedsecret,itgivessource
authentication
• Anti-replayprotection– Optional:thesendermustprovideitbuttherecipientmayignore
• KeyManagement– IKE– sessionnegotiationandestablishment– Sessionsarerekeyedordeletedautomatically– Secretkeysaresecurelyestablishedandauthenticated– Remotepeerisauthenticatedthroughvaryingoptions
IPsecComponents• AH(AuthenticationHeader)
– Authenticationisappliedtotheentirepacket,withthemutablefieldsintheIPheaderzeroedout
– IfbothESPandAHareappliedtoapacket,AHfollowsESP– StandardrequiresHMAC-MD5-96andHMAC-SHA1-96….olderimplementations
alsosupportkeyedMD5
• ESP(EncapsulatingSecurityPayload)– Mustencryptand/orauthenticateineachpacket– Encryptionoccursbeforeauthentication– AuthenticationisappliedtodataintheIPsec headeraswellasthedata
containedaspayload– StandardrequiresDES56-bitCBCandTripleDES.CanalsouseRC5,IDEA,
Blowfish,CAST,RC4,NULL
• IKE(InternetKeyExchange)– AutomatedSA(SecurityAssociation)creationandkeymanagement
28
InteroperableDefaultsForSAs• SecurityAssociationgroups
elementsofaconversationtogether
– ESPencryptionalgorithmandkey(s)
– Cryptographicsynchronization
– SAlifetime– SAsourceaddress– Mode(transportor
tunnel)
How Do WeCommunicate Securely ?
Do we want integrity protection of data ?Do we want to keep data confidential ?Which algorithms do we use ?What are the key lengths ?When do we want to create new keys ?Are we providing security end-to-end ?
29
IPsec withIKE
Traffic which needs to be protected is
recognized as requiringIPsec protection
IPsec PeerIPsec Peer
IKE Phase 1
Secure communication channel
IKE Phase 2
IPsec Tunnel
Secured traffic exchange
12
3
4
Peers Authenticate using:- Pre-shared key- Digital Certificate
30
Secured Communications
IPsecIKEPhase1UsesDHExchange
• Firstpublickeyalgorithm(1976)• DiffieHellmanisakeyestablishmentalgorithm– TwopartiesinaDFexchangecangenerateasharedsecret– TherecanevenbeN-partyDFchangeswhereNpeerscanallestablish
thesamesecretkey
• DiffieHellmancanbedoneoveraninsecurechannel
• IKEauthenticatesaDiffie-Hellmanexchange– Pre-sharedsecret– Nonce(RSAsignature)– Digitalsignature
31
IKEPhase1MainMode
ResponderInitiator
1
2
IKEMessage1(SAproposal)
IKEMessage2(acceptedSA)
IKEMessage3(DHpublicvalue,nonce)
IKEMessage4(DHpublicvalue,nonce)
IKEMessage5(Authenticationmaterial,ID)
IKEMessage6(Authenticationmaterial,ID)4
3
NegotiateIKEPolicy
AuthenticatedDHExchange
ComputeDHsharedsecretandderivekeyingmaterial
ProtectIKEPeerIdentity
Internet
(Encrypted)
32
33
IKEPhase2QuickMode
ResponderInitiator
3
Compute keying material
Internet
Message 1 (authentication/keying material and SA proposal)
Message 2 (authentication/keying material and accepted SA)
Message 3 (hash for proof of integrity/authentication)
1
2
5
Validatemessage 1
7
4
6Validate
message 3
Validatemessage 2
IKEv2:ReplacementforCurrentIKESpecification
• Feature Preservation– Most features and characteristics of baseline
IKE v1 protocol are being preserved in v2
• Compilation of Features andExtensions– Quite a few features that were added on top of
the baseline IKE protocol functionality in v1 are being reconciled into the mainline v2 framework
• Some New Features34
IKEv2:WhatIsNotChanging• Features in v1 that have been debated
but are ultimately being preserved in v2– Most payloads reused– Use of nonces to ensure uniqueness of keys
• v1 extensions and enhancements being merged into mainline v2 specification– Use of a ‘configuration payload’ similar to
MODECFG for address assignment– ‘X-auth’ type functionality retained through EAP– Use of NAT Discovery and NAT Traversal techniques
35
IKEv2:WhatIsChanging
• Significant Changes Being to the Baseline Functionality of IKE– EAP adopted as the method to provide legacy
authentication integration with IKE– Public signature keys and pre-shared keys,
the only methods of IKE authentication– Use of ‘stateless cookie’ to avoid certain
types of DOS attacks on IKE– Continuous phase of negotiation
36
HowDoesIKEv2Work?
IKE_SA_INIT(Two Messages)
IKE_AUTH (Two Messages)
Protected Data
IKE_SA AuthenticationParameters Negotiated
IKE Authentication Occursand One CHILD_SA Created
CREATE_CHILD_SA (Two Messages) Second CHILD_SA Created
37
RelevantStandard(s)• IETFspecific
– rfc2409:IKEv1– rfc4301:IPsec Architecture(updated)– rfc4303:IPsec ESP(updated)– rfc4306:IKEv2– rfc4718:IKEv2Clarifications– rfc4945:IPsec PKIProfile
• IPv6andIPsec– rfc4294:IPv6NodeRequirements– Rfc4552:Authentication/ConfidentialityforOSPFv3– rfc4877:MobileIPv6UsingIPsec (updated)– rfc4891:UsingIPsec tosecureIPv6-in-IPv4Tunnels
38
ConsiderationsForUsingIPsec• SecurityServices
– Dataoriginauthentication– Dataintegrity– Replayprotection– Confidentiality
• Sizeofnetwork• Howtrustedareendhosts– canaprioricommunicationpoliciesbecreated?
• Vendorsupport• Whatothermechanismscanaccomplishsimilarattackriskmitigation
39
Non-VendorSpecificDeploymentIssues
• HistoricalPerception– Configurationnightmare– Notinteroperable
• PerformancePerception– Needempiricaldata– Whereistherealperformancehit?
• StandardsNeedCohesion
40
VendorSpecificDeploymentIssues• Lackofinteroperabledefaults
– AdefaultdoesNOTmandateaspecificsecuritypolicy
– Defaultscanbemodifiedbyendusers
• Configurationcomplexity– Toomanyknobs– Vendor-specificterminology
• GoodNews:IPv6supportinmostcurrentimplementations
41
TransportvsTunnelMode
Transport Mode: End systems are the initiator and recipient of protected traffic
Tunnel Mode: Gateways act on behalf of hosts to protect traffic
Routing UpdateTFTP
File Transfer
File Transfer
42
IPsec Concerns
• AreenoughpeopleawarethatIKEv2isnotbackwardscompatiblewithIKEv1?– IKEv1isusedinmostIPsec implementations– WillIKEv2implementationsfirsttryIKEv2andthenreverttoIKEv1?
• IsIPsec implementedforIPv6?– SomeimplementationsshipIPv6capabledeviceswithoutIPsec
capabilityandhostrequirementsischangedfromMUSTtoSHOULDimplement
• OSPFv3– Allvendors‘IF’theyimplementIPsec usedAH– LateststandardtodescribehowtouseIPsec saysMUSTuseESP
w/NullencryptionandMAYuseAH
43
IPsec Concerns(cont)• Whatistransportmodeinteroperabilitystatus?– Willenduserauthenticationbeinteroperable?
• PKIIssues– Whichcertificatesdoyoutrust?– HowdoesIKEv1and/orIKEv2handleproposalswithcertificates?– Shouldcommontrustedrootsbeshippedbydefault?– Whoisfollowingandimplementingpki4ipsec-ikecert-profile(rfc4945)
• Havemobilityscenariosbeentested?– MobilitystandardsrelyheavilyonIKEv2
• ESP– howdetermineifESP-Nullvs Encrypted
44
45
IPv4IPsecAHOriginal
IP Header TCP/UDP Data
OriginalIP Header
AHHeader TCP/UDP Data
Beforeapplying AH:
After applying AH:
Authenticated except formutable fields in IP header
Mutable Fields:- ToS- TTL- Hdr Checksum- Offset- Flags
IPv4AHTransportMode:
OriginalIP Header TCP/UDP Data
NewIP Header
AHHeader Data
Before applying AH:
After applying AH:
Authenticated except formutable fields in new IP header
OriginalIP Header
Mutable Fields:- ToS- TTL- Hdr Checksum- Offset- Flags
IPv4AHTunnelMode:
TCP/UDP
46
IPv4IPsecESPOriginal
IP Header TCP/UDP Data
OriginalIP Header
ESPHeader
Before applying ESP:
After applying ESP:
Encrypted
ESPAuth
Authenticated
TCP/UDP DataESP
Trailer
OriginalIP Header TCP/UDP Data
NewIP Header
ESPHeader
Before applying ESP:
After applying ESP:
Encrypted
ESPAuth
Authenticated
OriginalIP Header TCP/UDP Data
ESPTrailer
IPv4ESPTransportMode:
IPv4ESPTunnelMode:
ESPHeaderFormat0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31
Next HeaderPadding Length
SPI: Arbitrary 32-bit number that specifies SA to the receiving device Seq #: Start at 1 and must never repeat; receiver may choose to ignore IV: Used to initialize CBC mode of an encryption algorithm Payload Data: Encrypted IP header, TCP or UDP header and dataPadding: Used for encryption algorithms which operate in CBC modePadding Length: Number of bytes added to the data stream (may be 0)Next Header: The type of protocol from the original header which appears in the
encrypted part of the packetAuth Data: ICV is a digital signature over the packet and it varies in length
depending on the algorithm used (SHA-1, MD5)
Payload Data (Variable)
Padding (0-255 bytes)
Initialization Vector (IV)
Sequence Number
Security Parameter Index (SPI)
Authentication Data (ICV)
ENC
RYP
TED
47
PotentiallyEasyConfiguration
RNOC- Mgmt
RNOC- Srvc2001:DB8:6665:AF75::3B
2001:DB8:6665:AF75::3DRouter_M
2001:DB8:6665:FAD::99
Router_Z2001:DB8:8888:BAD::66
Syslog server 2001:DB8:6665:AF75::3D authenticate esp-null sha1 pre-share ‘secret4syslog’
TFTP server 2001:DB8:6665:AF75::3D authenticate esp-null aes128 pre-share ‘secret4tftp’
BGP peer 2001:DB8:8888:BAD::66 authenticate esp-null aes128 pre-share ‘secret4AS#XXX’
48
PrettyGoodIPsecPolicy• IKEPhase1(akaISAKMPSAorIKESAorMainMode)
– 3DES(AES-192ifbothendssupportit)– Lifetime(8hours=480min=28800sec)– SHA-2(256bitkeys)– DHGroup14(akaMODP#14)
• IKEPhase2(akaIPsec SAorQuickMode)– 3DES(AES-192ifbothendssupportit)– Lifetime(1hour=60min=3600sec)– SHA-2(256bitkeys)– PFS2– DHGroup14(akaMODP#14)
49
HelpWithConfiguringIPsec• DocumentsforCiscoIPsecconfiguration:
– http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a0080093f73.shtml
– http://www.cisco.com/en/US/tech/tk583/tk372/technologies_configuration_example09186a0080093f86.shtml
• DocumentforJuniperIPsec configuration:– http://kb.juniper.net/InfoCenter/index?page=content&id=KB10128
50