1. Web Security and Email Security

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

3. Web security Threats

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

5. SSL

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

7. SSL architecture

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

9. SSL Message type

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

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

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

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

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

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

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

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

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

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

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

22. SET: overview

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

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

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

26. Dual Signature (2)

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

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

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

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

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

32. PGP

33. PGP in
PGP is based on five services: authentication, confidentiality, compression, compatibility, and segmentation.

34. PGP vs PEM
Student job