1 / 36

COMP3371 Internet Security

COMP3371 Internet Security. Richard Henson University of Worcester November 2018. Week 9: Securing Web Pages & Digital Certificates. Objectives: Explain how HTTPS/SSL/TLS fits into the OSI seven layer model

koehler
Télécharger la présentation

COMP3371 Internet Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

More Related