VPN, IPsec and TLS - rg.net · PDF fileVPN, IPsec and TLS ... – IP over PPP over GRE ... – IP over PPP over L2TP over UDP over ESP • IPsec – IP over ESP

VPN,IPsec andTLS

<[email protected]>stoleslidesfromMerike Kaeo

<[email protected]>

2016/2/16 1

VirtualPrivateNetwork

• OverlayNetwork– aVPNisbuiltontopofapublicnetwork(Internet)

• Costeffective– Youdon’tneedtoexpandyournetwork

• Rapidlydeployable– AnunderlaynetworkjustcarriesIPpacketsasusual– OnlyyournodesneedtoagreeaboutVPN

• Control– YoucanenforceyourownpolicyintheVPN

2016/2/16 2

satelliteoffice

2016/2/16 3

accesstointranetfromoutside

2016/2/16 4

overanuntrustednetwork

2016/2/16 5

IPv4andIPv6• pathtogetadestination• cacheDNS

2016/2/16 6

VPN andsecurity

• AnyVPNisnot automagically secure.YouneedtoaddsecurityfunctionalitytocreatesecureVPNs.ThatmeansusingfirewallsforaccesscontrolandprobablyIPsec orSSL/TLSforconfidentialityanddataoriginauthentication.

2016/2/16 7

VPNprotocols• PPTP

– IPoverPPPoverGRE– possiblepasswordleakagebyMS-CHAPv2weakness

• OpenVPN– IPoverTLSoverTCP/UDP

• MS-SSTP– IPoverPPPoverSSTPoverHTTPSoverTCP

• L2TP/IPsec– IPoverPPPoverL2TPoverUDPoverESP

• IPsec– IPoverESP– IPoverESPoverUDP(NATtraversal)

2016/2/16 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

2016/2/16

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!!

2016/2/16

IPSec

Internet

WhatIsIPSec?

• IETFstandardthatenablesencryptedcommunicationbetweenpeers:– Consistsofopenstandardsforsecuringprivatecommunications– Networklayerencryptionensuringdataconfidentiality,integrity,

andauthentication– Scalesfromsmalltoverylargenetworks

2016/2/16 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– Secretkeysaresecurelyestablished andauthenticated– Remotepeerisauthenticated throughvaryingoptions

2016/2/16

IPsecComponents• AH(AuthenticationHeader)

– Authentication isapplied totheentirepacket,withthemutablefieldsintheIPheaderzeroedout

– IfbothESPandAHareapplied toapacket,AHfollowsESP– StandardrequiresHMAC-MD5-96andHMAC-SHA1-96….older implementations

alsosupport keyedMD5

• ESP(EncapsulatingSecurityPayload)– Mustencryptand/orauthenticateineachpacket– Encryptionoccursbeforeauthentication– Authentication isapplied todataintheIPsec headeraswellasthedata

containedaspayload– StandardrequiresDES56-bitCBCandTripleDES.CanalsouseRC5,IDEA,

Blowfish,CAST,RC4,NULL

• IKE(InternetKeyExchange)– AutomatedSA(SecurityAssociation)creationandkeymanagement

132016/2/16

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 ?

142016/2/16

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

2016/2/16

IPsecIKEPhase1UsesDHExchange

• Firstpublickeyalgorithm(1976)• DiffieHellmanisakeyestablishmentalgorithm– TwopartiesinaDFexchangecangenerateasharedsecret– TherecanevenbeN-partyDFchangeswhereNpeerscanallestablish

thesamesecretkey

• DiffieHellmancanbedoneoveraninsecurechannel

• IKEauthenticatesaDiffie-Hellmanexchange– Pre-sharedsecret– Nonce(RSAsignature)– Digitalsignature

162016/2/16

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)

172016/2/16

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

2016/2/16

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 Features2016/2/16 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

2016/2/16 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

2016/2/16 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

2016/2/16 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

232016/2/16

ConsiderationsForUsingIPsec• SecurityServices

– Dataoriginauthentication– Dataintegrity– Replayprotection– Confidentiality

• Sizeofnetwork• Howtrustedareendhosts– canaprioricommunicationpoliciesbecreated?

• Vendorsupport• Whatothermechanismscanaccomplishsimilarattackriskmitigation

242016/2/16

Non-VendorSpecificDeploymentIssues

• HistoricalPerception– Configurationnightmare– Notinteroperable

• PerformancePerception– Needempiricaldata– Whereistherealperformancehit?

• StandardsNeedCohesion

252016/2/16

VendorSpecificDeploymentIssues• Lackofinteroperabledefaults

– AdefaultdoesNOTmandateaspecificsecuritypolicy

– Defaultscanbemodifiedbyendusers• Configurationcomplexity

– Toomanyknobs– Vendor-specificterminology

• GoodNews:IPv6supportinmostcurrentimplementations

262016/2/16

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

272016/2/16

IPsec Concerns

• AreenoughpeopleawarethatIKEv2isnotbackwardscompatiblewithIKEv1?– IKEv1isusedinmostIPsec implementations– WillIKEv2implementations firsttryIKEv2andthenreverttoIKEv1?

• IsIPsec implementedforIPv6?– Someimplementations shipIPv6capabledeviceswithoutIPsec

capabilityandhostrequirementsischangedfromMUSTtoSHOULDimplement

• OSPFv3– Allvendors‘IF’theyimplement IPsec usedAH– LateststandardtodescribehowtouseIPsec saysMUSTuseESP

w/NullencryptionandMAYuseAH

282016/2/16

IPsec Concerns(cont)• Whatistransportmodeinteroperabilitystatus?– Willenduserauthenticationbeinteroperable?

• PKIIssues– Whichcertificatesdoyoutrust?– HowdoesIKEv1and/orIKEv2handleproposalswithcertificates?– Shouldcommontrustedrootsbeshippedbydefault?– Whoisfollowingandimplementing pki4ipsec-ikecert-profile (rfc4945)

• Havemobilityscenariosbeentested?– MobilitystandardsrelyheavilyonIKEv2

• ESP– howdetermineifESP-Nullvs Encrypted

292016/2/16

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

2016/2/16

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:

2016/2/16

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

322016/2/16

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’

332016/2/16

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)

342016/2/16

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

352016/2/16

HTTPandSecureChannel

2016/2/16 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)

2016/2/16 37

SSLisnotsecureanymore

• SSL2.0andSSL3.0haveknownvulnerabilitiesinprotocolspecifications– downgradeattack– POODLEattack– RFC6176- ProhibitingSecureSocketsLayer(SSL)Version2.0

– RFC7568- DeprecatingSecureSocketsLayerVersion3.0

• UseTLSinstead

2016/2/16 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.

2016/2/16 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

2016/2/16

41

TLSClientAuthentication

- Clientauthentication(certificatebased)isoptionalandnotoftenused

- Manyapplicationprotocolsincorporatetheirownclientauthenticationmechanismsuchasusername/passwordorS/Key

- TheseauthenticationmechanismsaremoresecurewhenrunoverTLS

2016/2/16

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

2016/2/16 43

CertificateAuthority

• issuesadigitalcertificatewhichissignedbytheCA’sprivatekey

• Youcanverifythecertificateusingthecorrespondingpublickey– ifyoutrustthepublickey

• …andCAcanhavehierarchicaltrustmodel

2016/2/16 44

Trustchain

2016/2/16 45

rootCA

intermidiateCA

endentitycert

sign

sign

endentitycert

sign

https://www.apricot.net

2016/2/16 46

https://wiki.rg.net/

2016/2/16 47

trustedCA

2016/2/16 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

2016/2/16 49

CheckyourtrustedCA

• Windows– certlm.msc

• MacOSX– KeychainAccess.app

• Firefox– Setting->Advanced->Certificates->

ViewCertificates

2016/2/16 50

EncryptedCommunications• Useencryptedcommunicationswheneveryouneedtokeepinformationconfidential

• Verifyvianetworksniffer(e.g.wireshark)thatyourcommunicationisindeedencrypted

• Animportantaspectiscredentialmanagement(creating,distributing,storing,revoking,renewing)

• Understandif/whencredentialsarelostthatyoumaynotbeabletorecoverthedata

• Haveaplaninplaceincaseyouforgetyourpasswordthatprotectsyourprivatekeys

512016/2/16