COMP3123 Internet Security

1. COMP3123 Internet Security Richard Henson University of Worcester November2011

2. Week 8 Communications: Securing Web Pages • Objectives: • Explain how HTTPS/SSL/TLS fits into the OSI seven layer model • Take the necessary steps to implement an SSL system on a www server that uses EAP/TLS • Apply PKI principles to produce a workable 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. Secure Sockets and the Session Layer • In the early days of Unix, someone devised the concept of a logical “socket”: • protocol between application and transport layers that TCP could plug in to with the help of a TCP port • “socket” dealt with network authentication • with OSI, concept evolved into the session layer • When Windows (application layer) first interfaced with TCP/IP… • Session layer protocol known as WINSOCK

5. Secure HTTP (https) 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 Layer 7 “Session” Layer 4

6. Secure HTTP (https) and the session layer • Security can be imposed, by authenticating at the “logon” layer • username/password check is required before data can pass the session layer and be displayed by the browser • remote logon e.g. by Kerberos authentication Layer 7 “Session” Layer 4

7. The Trouble with HTTP • General Internet principle of “anyone can go anywhere” • On a Windows system with www access: • TCP can link to HTTP through “Winsock” • session layer authentication bypassed • HTML data transferred directly to the presentation and application layers for display • Problem (security): • the data is visible to anyone else on the Internet who may have access to that machine and the data path to it!

8. Secure HTTP and the user authentication problem • Even http can be set up at the server end to require authentication at the session layer… data not encrypted • SSL protocol can require a username/password combination before data passes through the socket from transport layer to application layer… encrypts by default application authentication required transport

9. SSL-based Authentication • SSL is able to use the PKI (remember that?) • When a user first attempts to communicate with a web server over a secure connection: • that server will present the web browser with authentication data • presented as a server certificate (remember those?) • verifies that the server is who and what it claims to be • Works both ways… • protocol: EAP/TLS • server may in return request client authentication via username/password

10. SSL 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 working at level 5/6 also ensures that it is: • encrypted before being sent • decrypted upon receipt and prior to processing for display

11. Confidentiality & Integrity • Encryption of SSL responses can be • standard 40 bit RSA • one time difficult to break confidentiality • 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. Is an SSL Digital Certificate Really Necessary? • Yes: • for sites involved in e-commerce and therefore involving digital payment with authentication • any other business transaction in which authentication is important • No: • if an administrator simply wants to ensure that data being transmitted and received by the server is private and cannot be snooped by anyone eavesdropping on the connection • In such cases, a self-signed certificate is sufficient

13. The Web of Trust (PGP) • Based on individual trust networks built up between individuals • Possible to “self sign” a digital certificate • if someone trusts you, a self-signature may be all they need • OpenPGP identiity certificates are designed to be self-signed

14. Verisign Trust System • Web of Trust • OK for academics (“good” people?) • but bad” people can do business • Verisign system presented as an alternative • developed so that people could trust strangers in business transactions • financial institutions provide the “trust”

15. General Tips on Running SSL • Secure websites… • designed to be as efficient as securely possible • problem: encryption/decryption is computationally expensive from a performance standpoint • not strictly necessary to run an entire Web application over SSL • customary for a developer to: • find out which pages require a secure connection and which do not • create secure and non-secure folder structures for the respective web pages

16. When to use SSL • 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

17. HTTPS • A client-server service that runs on the Web server (by default, on TCP port 443) • uniquely designed so it will not run on a server without an installed and active server certificate • Once the service has been set up, https will require users to establish an encrypted channel with the server • i.e. https:// • rather than http:// • Until the user does use https they will get an error, rather than the pop up that proceeds the secure web page

18. Why not use HTTPS? • Encryption can interfere with access to data… (i.e. availability) • an encrypted channel running https requires … • that the user's Web browser and the Web server BOTH support the same encryption scheme • And have the appropriate key(s) • for example: • IF an IIS Web Server is set to use default secure communication settings • THEN the client Web browser must support a session key strength of 40 bits, or greater

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

20. Browser Prompts: Web Page delivered securely using SSL • (depending on browser settings) A pop up appears… • informs the client that they are entering a secure client-server connection • pop up must be acknowledged to continue • When page is be displayed: • https:// will appear before the URL • A “lock” symbol appears on the bottom left of the screen

21. “Virtual Hosts” (http) • Useful technology for ISPs • Enables many different folders/websites to be used in conjunction with a web server • but all have the same IP address!! • Done by careful mapping with the real domain name that corresponds to the IP address • even though the folder names appear to have different URLs • they all originate from the same domain name

22. “Virtual Hosts” and SSL • The SSL “handshake”, where the client browser accepts the server certificate, must occur before the HTTP request is accessed • i.e. at a lower OSI layer… • Consequences: • the request information containing a virtual host name cannot be determined prior to authentication • therefore not possible to assign multiple certificates to a single IP address • Using name-based virtual hosts on a secured connection is therefore problematic…

23. Virtual Hosts and SSL • If all the virtual hosts on a single IP address will need to authenticate against the same certificate… • multiple “virtual hosts” should not interfere with normal SSL operations on the server • However • most client browsers will compare the server's domain name against the domain name listed in the certificate • if the domain names don’t match, these browsers will display a warning pop-up message to the client • may cause unnecessary alarm at the client end!

24. VPNs using SSL • Http-based applications and access are now potentially available to anyone with a browser • browsers how available for portable devices… • the whole nature of keeping data secure has changed… • SSL VPN’s developed to: • complement existing SSL implementations • increase the level of access control and security • address the challenge of increased risks of fraud, threats and hacks that could compromise the security of application access

25. The apparent contradiction of SSL VPN • By now, you should understand what SSL and VPN means independently, but what does this new phrase mean together? • To sum up, SSL works at OSI layers 5-7: • secures data over the Internet with encryption that is automatically enabled in every browser • requires a certificate is needed for the web server, but turning on SSL is relatively straightforward for an application • doesn’t work with all applications and changing some links might be needed, but this depends solely on the application

26. The apparent contradiction of SSL VPN • Conventional VPNs, on the other hand: • focus around virtually connecting networks • always associated with IPSec (level 1, 2, 3) • the de-facto protocol used to encrypt traffic for VPN • ensure privacy of the data and a certain level of access control • IPSec VPNs are used to securely connect devices • across the physical network • across two networks • between two end-points

27. So, how can SSL and VPN work together successfully? • 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

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

29. SSL VPNs or IPSec VPNs? (horses for courses) • IPsec still seen as the 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 • As soon as the structure becomes cross-platform, intranetwork, across the firewall to the Internet… • SSL VPN using an Internet browser is a more effective solution than IPSec

30. Securely supporting Wireless Users • One of the big issues of the current times: • management want users out in “the field” to use wireless devices to communicate with base • IT managers worried about security… • Hence articles like this: • “IT security is broken, so can companies stay safe?” • BBC business reporter writing about BBC IT network • http://www.bbc.co.uk/news/business-11793436

31. 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 • Bluetooth • The IP protocol is slightly changed to cope with these standards

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

33. VPNs use a specified route… e.g. VPN shown in green

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

35. Wireless access andSSL VPNs • Another job for SSL VPNs… • allow authentication and authorization of users from anywhere • ensure secure access to all resources • Traditional wireless LAN model • WEP (Wireless Encryption Protocol) security based on authentication keys: • shared by anyone accessing that wireless hub • therefore additional support steps to regularly update and maintain security • More practical alternative: • Internet café model • all wireless users in proximity of a wireless hotspot can view a portal • but denied access “inside” unless they confirm authentication

36. Wireless SSL VPNs • In an enterprise wireless network scenario, wireless users can be directed through a suitably configured SSL VPN • but denied access to any resources until they log in for authentication • Provides central control of access to resources through a single gateway • whether users log in from: • a docked laptop at their desk • an undocked laptop in a conference room • a handheld PDA from elsewhere on the campus

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

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

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

40. Security Controls on Complex Networks • Group of British security researchers and professionals coined the phrase • Information Security Management System (ISMS) • British Standard for an ISMS emerged in the 1990s • BSI7799 • over 130 information security controls • many not technical • require management control of user behaviour

41. Process-based Information Security • ISMS development process based: • uses PCDA • Plan • Do • Check • Act • contrast with PCI-DSS check list • ISO27001 Certification awarded to organisations who appropriately use the process model covering the 130+ controls

42. International Standard for ISMS • BSI 7799 evolved (2005) into an International Standard ISO27001 • Soon became popular in Japan & along Pacific Rim • Also in some Eastern European countries • some UK interest • but most companies have not become certificated • WHY???

43. SMEs and Developing an ISMS • ISO27001 difficult for SMEs • especially information risk assessment • yet if they could engage, could identify greatest risks and reduce controls • IASME (Information Assurance for SMEs) developed by University of Worcester, NCC & experienced consultants assistance from govt funding (Technology Strategy Board) • makes risk assessment doable • takes into account small business culture • released this year… 2011

44. Thanks for Listening