COMP3371 Internet Security Richard Henson University of Worcester December 2017

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

Reminder: TCP/IP model Zoom in on TCP and the upper layers… TELNET FTP SMTP http-s HTTP Level 7 Session layer protocols: eg Unix “sockets”, SSL Level 5 TCP/TLS Level 4

HTTP and the session 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 hopeless for security! Layer 7 “Session” Layer 4

HTTP client security and 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

Web Pages, authentication and encryption in transit Even http can be set up at the server end to require authentication at the session layer… data not encrypted SSL protocol provides server authentication & in transit protection against MITM attacks achieved through Digital Certificates application authentication required transport

SSL-based Authentication Whole thing started with Netscape (browser company). No IETF involvement at this stage SSLv 2: 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 SSL probably started off the “secure Internet” movement that led to the IETF developing PKI: gradually, TLS (RFC 2246) became the favoured protocol

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 Works both ways… server may in return request client authentication via username/password

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

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)

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

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 OpenPGP self-signed certificate is sufficient

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

Verisign Trust System Web of Trust OK for academics (“good” people?) but “bad” people can do business 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)

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

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…

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

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!

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!

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?

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

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

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

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!

https and VPN working together Compared to IPSec, SSL VPNs provide the best technological solution to the business problem of: easily and securely connecting end users on the move to critical corporate data Any machine with a browser can use SSL VPN’s traditional VPN needs to have a physical client installed on every machine used for access SSL provides an easy to use avenue to access information, replacing the difficult to use VPN client/IPsec

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

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…

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)

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 WiFi protocol within this standard… WPA 2.0 (with patch applied!) Bluetooth initially low range but now up to 100 metres!

Wireless Data is Broadcast… lurker source destination lurker lurker

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

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

Wireless access and SSL VPNs Another job for SSL VPNs… allow authentication and authorization of users from anywhere ensure secure access to all resources “Traditional” wireless LAN model WPA2 security based on authentication keys Could be shared by anyone accessing that wireless hub More practical alternative: Internet café model all wireless users in proximity of a wireless hotspot can view a portal denied access “inside” unless they confirm authentication

Wireless SSL VPNs In an enterprise wireless network scenario, Internet café model applied using WPA2 authentication Central control of access to resources through a single gateway whether users log in from: a cabled laptop at their desk an undocked laptop in a conference room a smartphone elsewhere on the campus (via hotspot)

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

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

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

Thanks for Listening 