Web Security and Email Security

Web Security Introduction WWW is fundamentally a client/server application running over internet or TCP/IP intranet Why web security is challenging and important The internet is two way. Unlike traditional broadcasting system web is vulnerable to attack Reputation and money can be lost if web server of a company is compromised Once web server is compromised attacker may be able to gain access to data and system that is not part of web itself but connected to server at local site Causal and untrained users are common client for web-based service. This makes web more vulnerable

Web security Threats

Secure Socket Layer SSL is the standard security technology for establishing an encrypted link between a web server and a browser. This link ensures that all data passed between the web server and browsers remain private and integral. SSL is an industry standard Is used by millions of websites in the protection of their online transactions with their customers.

SSL

SSL Architecture Connection: A connection is a transport that provides a suitable type of service. For SSL, such connections are peer-to-peer relationships. The connections are transient (short period of time). Every connection is associated with one session. Session: An SSL session is an association between a client and a server. Sessions are created by the Handshake Protocol. Sessions define a set of cryptographic security parameters which can be shared among multiple connections. Sessions are used to avoid the expensive negotiation of new security parameters for each connection.

SSL architecture

SSL handshake Most complex part in SSL This protocol allows the server and client to authenticate each other It negotiate an encryption and MAC algorithm Cryptographic Keys to be used are sent The Handshake Protocol consists of a series of messages exchanged by client and server. All of these have the format. Each message has three fields: Type (1 byte): Indicates one of 10 messages. Length (3 bytes): The length of the message in bytes. Content ( >=0bytes): The parameters associated with this message

SSL Message type

SSL version Three version V1.0, v2.0, v3.0 All version published be Netscape Version 1.0 never made public due to various security flaw Version 2.0 was prohibited in 2011 by RFC 6176 A Request for Comments (RFC) is a formal document from the Internet Engineering Task Force ( IETF ) that is the result of committee drafting and subsequent review by interested parties. SSL 3.0 was deprecated in June 2015 by RFC 7568

Transport Layer Security TLS is Internet Engineering Task Force (IETF) standardization whose goal is to produce internet standard version of SSL Successor of TLS Similar but more secure to SSL Four version including one drafted version Security feature added more in each version

TLS v1.0 TLS 1.0 was first defined in RFC 2246 in January 1999 as an upgrade of SSL Version 3.0 Minor improvement TLS 1.0 does include a means by which a TLS implementation can downgrade the connection to SSL 3.0, thus weakening security

TLS V1.1 TLS 1.1 was defined in RFC 4346 in April 2006. It is an update from TLS version 1.0. Upgrades include Added protection against cipher-block chaining (CBC) attacks. Support for IANA registration of parameters Internet Assigned Numbers Authority

TLS V 1.2 Was defined in RFC 5246 in August 2008. Improvement The MD5-SHA-1 was replaced with SHA-256, Enhancement in the client's and server's ability to specify which hash and signature algorithms they accept. Expansion of support for authenticated encryption ciphers, used mainly for Galois/Counter Mode (GCM) and CCM mode of Advanced Encryption Standard encryption. TLS Extensions definition and Advanced Encryption Standard cipher suites were added. From 2011 backward negotiation removed for security purpose

TLS V1.3 TLS 1.3 is a working draft Details are provisional and incomplete

HTTPS HTTP over SSL Combination of HTTP and SSL (or TLS) Built into all modern web brower Depends of web server supporting HTTPS HTTP connection uses port 80, HTTPS uses port 443

Encryption on HTTPS Following elements are encrypted when HTTPS is used URL of the requested document Content of document Contents of browser forms Cookies sent from browser to server and server to browser Contents of HTTP header

Secure Electronic Transaction Secure Electronic Transaction (SET) was a communications protocol standard for securing credit card transactions over insecure networks SET was intended to become the de facto standard payment method on the Internet between the merchants, the buyers, and the credit- card companies. Not used now a days VISA now promotes the 3-D secure scheme

SET: Key feature Confidentiality of information Integrity of data Cardholder account authentication Merchant authentication

SET: Participant Cardholder Merchant Issuer Acquirer financial (institution that processes credit or debit card payments on behalf of a merchant) Payment gateway Certification authority

SET: overview

How it works Both cardholders and merchants must register with CA (certificate authority) first, before they can buy or sell on the Internet. Once registration is done, cardholder and merchant can start to do transactions, which involve 9 basic steps in this protocol, which is simplified. Customer browses website and decides on what to purchase Customer sends order and payment information, which includes 2 parts in one message: a. Purchase Order – this part is for merchant b. Card Information – this part is for merchant’s bank only.

How it works (2) Merchant forwards card information (part b) to their bank Merchant’s bank checks with Issuer for payment authorization Issuer send authorization to Merchant’s bank Merchant’s bank send authorization to merchant Merchant completes the order and sends confirmation to the customer Merchant captures the transaction from their bank Issuer prints credit card bill (invoice) to customer

Dual Signature Motivation from SET .Customer wants to send the order information (OI) to the merchant and the payment information (PI) to the bank. The merchant does not need to know the customer's credit-card number, and the bank does not need to know the details of the customer's order. The customer is afforded extra protection in terms of privacy by keeping these two items separate. However, the two items must be linked in a way that can be used to resolve disputes if necessary. The link is needed so that the customer can prove that this payment is intended for this order and not for some other goods or service.

Dual Signature (2)

Dual Signature The message digest (MD) of the OI and the PI are independently calculated by the customer. The dual signature is the encrypted MD (with the customer's secret key) of the concatenated MD's of PI and OI. The dual signature is sent to both the merchant and the bank. The protocol arranges for the merchant to see the MD of the PI without seeing the PI itself, and the bank sees the MD of the OI but not the OI itself. The dual signature can be verified using the MD of the OI or PI. It doesn't require the OI or PI itself. Its MD does not reveal the content of the OI or PI, and thus privacy is preserved.

Payment Processing Purchase Request Payment Authorization Consists four message - initiate Request, Initiate Response, Purchase Response Payment Authorization The merchant authorizes the transaction with the payment gateway. The payment authorization ensures that the transaction was approved by the issuer. Exchange consists of two messages: Authorization Request and Authorization response. Payment Capture To obtain payment, the merchant engages the payment gateway in a payment capture transaction, consisting of a capture request and a capture response message For the Capture Request message, the merchant generates, signs, and encrypts a capture request block, which includes the payment amount and the transaction ID. The message also includes the encrypted capture token received earlier for this transaction, as well as the merchant‘s signature key and key-exchange key certificates.

EMAIL Method of exchanging digital message Basically uses SMTP of TCP/IP SMTP is sufficient but only capable of queuing message is recipient end Thus used with POP3 or IMAP(Internet Message Access Protocol)

Email Security From an individual/end user standpoint, proactive email security measures include: Strong passwords Password change Spam filters Desktop-based anti-virus/anti-spam applications

PEM Privacy-Enhanced Email Very beginning for email security Used PKI (Public key infracture) to encrypt and decrypt email message

PGP

PGP in EMAIL PGP is based on five services: authentication, confidentiality, compression, e-mail compatibility, and segmentation.

PGP vs PEM Student job