COMP3371 Internet Security

1. COMP3371 Internet Security Richard Henson University of Worcester November2018

2. Week 9: Securing Web Pages & Digital Certificates • Objectives: • Explain how HTTPS/SSL/TLS fits into the OSI seven layer model • Explain the principles of EAP and Digital Certificates and identify the types of digital certificate in commercial/other use • Apply PKI principles to produce a workable solution for protecting web pages at the client end

3. Reminder: TCP/IP model • Zoom in on TCP and the upper layers… HTTP-S DNS FTP SMTP HTTP Level 7 Session layer protocols: eg Unix “sockets”, SSL Level 5 TCP/TLS or UDP Level 4

4. HTTP& the session (logon) layer • Application layer protocols communicate with TCP layer through unique TCP logical ports via (optional) session layer logon • Anonymous ftp, http, etc… bypass session layer • no authentication • great for availability • hopeless for confidentiality! Layer 7 “Session” Layer 4

5. HTTP client securityand the session layer • HTTP security COULD be imposed by the webserver, simply by authenticating at the “logon” layer • Username/password check required at client-end before data can pass the session layer and be displayed by the browser • BUT… no server-side check! Layer 7 “Session” Layer 4

6. Web Pages, authentication and encryption in transit • httpcan be set up at the server end to require authentication at the session layer… • data not encrypted! • https & SSL protocol provides server authentication & in transit protection against MITM attacks • provided Digital Certificatesappropriately applied! application authentication required transport

7. SSL-based Authentication • SSL probably started off the “secure Internet” movement that led to the IETF developing PKI: • Whole thing started with Netscape (browser company). No IETF involvement until later • SSLv2: • Hickman, Kipp, "The SSL Protocol", Netscape Communications Corp., Feb 9, 1995. Completely original work! • SSLv3: • A. Frier, P. Karlton, and P. Kocher, "The SSL 3.0 Protocol", Netscape Communications Corp., Nov 18, 1996, Netscape in co-operation with industry • gradually, TLS (RFC 2246) became the favoured protocol

8. Mechanism for HTTPS using SSL • When user/client requests a secure web page from a web server over a secure connection: • that server will present the web browser with authentication by making a server certificate available • verifies that the server is who and what it claims to be • protocol: EAP/TLS https Web server Web browser https

9. Client Authentication • Works both ways… • server may in return request client authentication via username/password • client certificates can also be used…

10. SSL/TLS and Encryption • Authenticating the user & server only helps when the data is at its at its source or destination • data also needs to be protected in transit… • SSL can also ensure that html data is: • encrypted before being sent • decrypted upon receipt and prior to processing for display

11. Role of TLS DISPLAY OF DATA • https is only effective with both encryption and authentication are… • verified assured via Digital Certificate • TLS protocol provides encryption at transport layer -> protection against MITM attacks • encryption level verified through Digital Certificates Application Session layer (SSL) Transport (decryption)

12. Confidentiality & Integrity • Encryption of SSL/TLS can be • standard 40 bit RSA • “weak” • secure 128 bit RSA • difficult to “crack” even now • Guarantee that the data will not be modified in transit by a third party • integrity therefore also maintained

13. When is a Signed SSL Digital Certificate Essential? • For sites involved in e-commerce and therefore involving digital payment with authentication • For any other business transaction in which authentication is important • Not needed: • if an administrator simply wants to ensure that data being transmitted and received by the server is private (i.e. prevent MITM attacks) • in such cases, an OpenPGPself-signed certificate is sufficient

14. Self-signed Certificates and “The Web of Trust” (PGP) • OpenPGP identity certificates are designed to be self-signed • based on individual trust networks built up between individuals • IETF accepted as RFC 2440 • “self signing” based on: • if someone trusts you, a self-signature plus encryption is good enough for them

15. Verisign Trust System • Web of Trust • OK for academics (“good” people?) • but “bad” people can do business • https://www.youtube.com/watch?v=LRMBZhdFjDI • Verisign system presented as an alternative “Signed Certificates” • developed so that people could trust strangers in business transactions • financial institutions provide the “trust” • accepted by IETF as RFC 2459 (Jan 1999)

16. Types of “Signed” Digital Certificate • Although “SSL” is being phased out as protocol and replaced by the favoured TLS v2, the signed certificates are still called “SSL certificates” • Three types: • EV: extended validated • DV: domain validated • OV: organisation validated

17. Extended Validated (EV) • Highly recommend to e-commerce, government and financial sectors • customer’s trust is the prime factor • URL display in green • Follows industry (IETF etc.) good practice • displays 3 padlocks • expensive! • 7-10 days for issue…

18. Organisation Validated • Best suited for SMEs to reassure customers who they are: • reasonable price • Issued in a couple of days • display 2 padlocks

19. Domain Validated (DV) • Ideal for small, medium or forum websites where no financial interaction or business “trust” is needed • issued in minutes • cheap! • displays one padlock!

20. HTTPS • A client-server service • runs on the Web server • by default, on TCP port 443 • uniquely designed so it will not run on a server that doesn’t have an installed and active server certificate • https requires clints/users to establish an encrypted channel with the server • i.e. https:// • or user get an error, rather than a web page!

21. Why not use HTTPS? • Encryption can interfere with “availability”… (page takes longer to load at client end…) • an encrypted channel running https requires … • that the user's Web browser and the Web server BOTH support the same encryption scheme and algorithm (e.g. 40, 128, 256 bit, RSA) • if data is not secure e.g. page that the organisation wants everyone to see… • why bother with encryption?

22. General Tips on Organising SSL use on websites • Commercial websites… • designed to be as efficient as securely possible • problem: encryption/decryption “computationally expensive” (i.e. uses a lot of resources & slows things down) • not strictly necessary to run an entire Web application over SSL • Developer should: • find out which pages require a secure connection and which do not • create secure and non-secure folder structures for the respective web page types

23. When to use SSL/TLS • Whenever web pages require a secure connection with the server e.g.: • login pages • personal information pages • shopping cart checkouts • any pages where credit card information could possibly be transmitted

24. Accessing a Web Page using HTTPS • If the client is to request a page that needs SSL: • in the HTML code that will call that page, prefix the address with https:// instead of http:// and the system will do the rest • Any pages which absolutely require a secure connection should: • check the protocol type associated with the page request • take the appropriate action if https: is not specified

25. Recent rethink of http v https • Accepted that https is better for security: • http with an web page input form very bad practice • In EU infringes the DPA • However, US government now requires all government/local government websites to be solely https!

26. SSL, multiple machines and the flexible VPN • As SSL is embedded in the browser… • no need for client software! • if users have several machines (Home, work, client site, mobile device) they use the browser to connect • makes life much easier • Yet VPN describes secure remote access tunnels to individual clients and servers… • at an academic level…. • the two concepts of VPN & SSL used together seem to contradict • in reality • present a solution to technological demands of the mobile devices & secure remote access

27. SSL VPNs or IPSec VPNs? (horses for courses) • IPsec VPNs: standard for secure inter-office networking (i.e. where there are no complications): • common platform of office PCs • no need to send data across complex infrastructures or firewalls • SSL VPN more effective as soon as the structure becomes cross-platform, intranetwork, across the firewall to the Internet, etc…

28. Securely supporting Wireless Users • Continuing big issue of current times (BYOD): • management want users out in “the field” to use wireless devices to communicate with base • IT managers worried about security… • Upper OSI layers (transport-application) much more appropriate for enforcing strong encryption & effective authentication (EAPS)

29. Wireless Protocols • Current standards for wireless connections at lower OSI layers developed by the IEEE (Institute of Electrical and Electronic Engineers) and manufacturers are: • IEEE802.11g • WiFiprotocol within this standard… WPA 2.0 (with patch applied!) • Bluetooth • initially low range but now up to 100 metres!

30. Wireless Data is Broadcast… lurker source destination lurker lurker

31. Traditional VPNs: specified route… e.g. VPN shown in green

32. Protecting Wireless access • Because packets are easily intercepted the data absolutely MUST be encrypted • In the unlikely scenario that the interceptor: • works out the encryption method • and intercepts the encryption key… • data could be further safeguarded by use of VPN techniques • e.g. tunnelling and encapsulation

33. A Secure Wireless Network Scenario (1) • The organisation establishes an array of WiFi access points distributed across the campus • wireless hubs located in multiple buildings • On entering range of a “hotspot”; • all wireless users may connect to the Internet • but no access to any internal or external (public Internet) resources • when wireless network user launches a browser, immediately redirected to a login page for authentication through the SSL VPN

34. A Secure Wireless Scenario (2) • Wireless user uses username/password for authentication • Once authenticated, software agents can quickly do a background scan of user's end point device: • detect its identity and integrity: • check for the presence of valid software certificates • check up-to-dateness of antivirus software & Windows patches

35. A Secure Wireless Scenario (3) • If the device meets the scan criteria: • user is fully authorized • then presented with a portal for accessing their network files, applications and directories based on their role and privileges • Otherwise the user can be automatically be: • either redirected to a quarantined site offering easy self-remediation steps • or denied access to the network altogether

36. Summary of Digital Certificates (c. 2011 but explains the concepts beautifully…):https://www.youtube.com/watch?v=SJJmoDZ3il8Thanks for Listening!