VPN, IPsecand TLS - rg.net · Transport vs Tunnel Mode Transport Mode : End systems are the initiator and recipient of protected traffic Tunnel Mode : Gateways act on behalf of hosts

VPN,IPsec andTLS

<[email protected]>stoleslidesfromMerike Kaeo

<[email protected]>

apricot2017 1

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


NewIP Header

ESPHeader

Before applying ESP:

After applying ESP:

Encrypted

ESPAuth

Authenticated


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