440 likes | 538 Views
COMP3123 Internet Security. Richard Henson University of Worcester November 2011. 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
E N D
COMP3123 Internet Security Richard Henson University of Worcester November2011
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
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
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
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
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
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!
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
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
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
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
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
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
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”
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
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
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
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
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
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
“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
“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…
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!
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
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
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
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
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 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
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
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
Wireless Data is Broadcast… lurker source destination lurker lurker
VPNs use a 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 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
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
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
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
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
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???
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