vpn, ipsecand tls - rg.net · transport vs tunnel mode transport mode : end systems are the...
TRANSCRIPT
VirtualPrivateNetwork
• OverlayNetwork– aVPNisbuiltontopofapublicnetwork(Internet)
• Costeffective– Youdon’tneedtoexpandyournetwork
• Rapidlydeployable– AnunderlaynetworkjustcarriesIPpacketsasusual– OnlyyournodesneedtoagreeaboutVPN
• Control– YoucanenforceyourownpolicyintheVPN
apricot2017 2
satelliteoffice
apricot2017 3
accesstointranetfromoutside
apricot2017 4
overanuntrustednetwork
apricot2017 5
IPv4andIPv6• pathtogetadestination• cacheDNS
apricot2017 6
VPN andsecurity
• AnyVPNisnot automagically secure.YouneedtoaddsecurityfunctionalitytocreatesecureVPNs.ThatmeansusingfirewallsforaccesscontrolandprobablyIPsec orSSL/TLSforconfidentialityanddataoriginauthentication.
apricot2017 7
VPNprotocols• PPTP
– IPoverPPPoverGRE– possiblepasswordleakagebyMS-CHAPv2weakness
• OpenVPN– IPoverTLSoverTCP/UDP
• MS-SSTP– IPoverPPPoverSSTPoverHTTPSoverTCP
• L2TP/IPsec– IPoverPPPoverL2TPoverUDPoverESP
• IPsec– IPoverESP– IPoverESPoverUDP(NATtraversal)
apricot2017 8
9
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
apricot2017
10
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!!
apricot2017
IPSec
Internet
WhatIsIPSec?
• IETFstandardthatenablesencryptedcommunicationbetweenpeers:– Consistsofopenstandardsforsecuringprivatecommunications– Networklayerencryptionensuringdataconfidentiality,integrity,
andauthentication– Scalesfromsmalltoverylargenetworks
apricot2017 11
12
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
apricot2017
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
13apricot2017
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 ?
14apricot2017
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
15
Secured Communications
apricot2017
IPsecIKEPhase1UsesDHExchange
• Firstpublickeyalgorithm(1976)• DiffieHellmanisakeyestablishmentalgorithm– TwopartiesinaDFexchangecangenerateasharedsecret– TherecanevenbeN-partyDFchangeswhereNpeerscanallestablish
thesamesecretkey
• DiffieHellmancanbedoneoveraninsecurechannel
• IKEauthenticatesaDiffie-Hellmanexchange– Pre-sharedsecret– Nonce(RSAsignature)– Digitalsignature
16apricot2017
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)
17apricot2017
18
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
apricot2017
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 Featuresapricot2017 19
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
apricot2017 20
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
apricot2017 21
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
apricot2017 22
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
23apricot2017
ConsiderationsForUsingIPsec• SecurityServices
– Dataoriginauthentication– Dataintegrity– Replayprotection– Confidentiality
• Sizeofnetwork• Howtrustedareendhosts– canaprioricommunicationpoliciesbecreated?
• Vendorsupport• Whatothermechanismscanaccomplishsimilarattackriskmitigation
24apricot2017
Non-VendorSpecificDeploymentIssues
• HistoricalPerception– Configurationnightmare– Notinteroperable
• PerformancePerception– Needempiricaldata– Whereistherealperformancehit?
• StandardsNeedCohesion
25apricot2017
VendorSpecificDeploymentIssues• Lackofinteroperabledefaults
– AdefaultdoesNOTmandateaspecificsecuritypolicy
– Defaultscanbemodifiedbyendusers
• Configurationcomplexity– Toomanyknobs– Vendor-specificterminology
• GoodNews:IPv6supportinmostcurrentimplementations
26apricot2017
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
27apricot2017
IPsec Concerns
• AreenoughpeopleawarethatIKEv2isnotbackwardscompatiblewithIKEv1?– IKEv1isusedinmostIPsec implementations– WillIKEv2implementationsfirsttryIKEv2andthenreverttoIKEv1?
• IsIPsec implementedforIPv6?– SomeimplementationsshipIPv6capabledeviceswithoutIPsec
capabilityandhostrequirementsischangedfromMUSTtoSHOULDimplement
• OSPFv3– Allvendors‘IF’theyimplementIPsec usedAH– LateststandardtodescribehowtouseIPsec saysMUSTuseESP
w/NullencryptionandMAYuseAH
28apricot2017
IPsec Concerns(cont)• Whatistransportmodeinteroperabilitystatus?– Willenduserauthenticationbeinteroperable?
• PKIIssues– Whichcertificatesdoyoutrust?– HowdoesIKEv1and/orIKEv2handleproposalswithcertificates?– Shouldcommontrustedrootsbeshippedbydefault?– Whoisfollowingandimplementingpki4ipsec-ikecert-profile(rfc4945)
• Havemobilityscenariosbeentested?– MobilitystandardsrelyheavilyonIKEv2
• ESP– howdetermineifESP-Nullvs Encrypted
29apricot2017
30
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
apricot2017
31
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:
apricot2017
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
32apricot2017
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’
33apricot2017
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)
34apricot2017
HelpWithConfiguringIPsec• http://www.vpnc.org/InteropProfiles/• DocumentsforCiscoIPsec configuration:
– 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
35apricot2017
HTTPandSecureChannel
apricot2017 36
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)
apricot2017 37
SSLisnotsecureanymore
• SSL2.0andSSL3.0haveknownvulnerabilitiesinprotocolspecifications– downgradeattack– POODLEattack– RFC6176- ProhibitingSecureSocketsLayer(SSL)Version2.0
– RFC7568- DeprecatingSecureSocketsLayerVersion3.0
• UseTLSinstead
apricot2017 38
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.
apricot2017 39
40
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
apricot2017
41
TLSClientAuthentication
- Clientauthentication(certificatebased)isoptionalandnotoftenused
- Manyapplicationprotocolsincorporatetheirownclientauthenticationmechanismsuchasusername/passwordorS/Key
- TheseauthenticationmechanismsaremoresecurewhenrunoverTLS
apricot2017
42
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
apricot2017 43
CertificateAuthority
• issuesadigitalcertificatewhichissignedbytheCA’sprivatekey
• Youcanverifythecertificateusingthecorrespondingpublickey– ifyoutrustthepublickey
• …andCAcanhavehierarchicaltrustmodel
apricot2017 44
Trustchain
apricot2017 45
rootCA
intermidiateCA
endentitycert
sign
sign
endentitycert
sign
https://www.apricot.net
apricot2017 46
https://wiki.rg.net/
apricot2017 47
trustedCA
apricot2017 48
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
apricot2017 49
CheckyourtrustedCA
• Windows– certlm.msc
• MacOSX– KeychainAccess.app
• Firefox– Setting->Advanced->Certificates->
ViewCertificates
apricot2017 50
EncryptedCommunications• Useencryptedcommunicationswheneveryouneedtokeepinformationconfidential
• Verifyvianetworksniffer(e.g.wireshark)thatyourcommunicationisindeedencrypted
• Animportantaspectiscredentialmanagement(creating,distributing,storing,revoking,renewing)
• Understandif/whencredentialsarelostthatyoumaynotbeabletorecoverthedata
• Haveaplaninplaceincaseyouforgetyourpasswordthatprotectsyourprivatekeys
51apricot2017