1. COMP3371 Internet Security
Richard Henson
University of Worcester
December 2017

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…
TELNET
FTP
SMTP
http-s
HTTP
Level 7
Session layer protocols: eg Unix “sockets”, SSL
Level 5
TCP/TLS
Level 4

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

5. 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

6. 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

7. 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, 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

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

9. 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

10. 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)

11. 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

12. 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

13. 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

14. 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)

15. 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

16. 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…

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

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

19. 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.
or user get an error, rather than a web page!

20. 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?

21. 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

22. 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

23. 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 instead of 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

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

25. 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

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
WiFi protocol 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. 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

34. 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)

35. 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

36. 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

37. 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

38. Thanks for Listening 