Successfully reported this slideshow.

BAIT1103 Chapter 4


Published on

Published in: Education, Technology
  • Be the first to comment

  • Be the first to like this

BAIT1103 Chapter 4

  1. 1. Chapter 4 Web Security
  2. 2. objectives • Summarize Web security threats and web traffic security approaches. • Present an overview of Secure Sockets Layer (SSL). • Understand the differences between Secure Sockets Layer and Transport Layer Security. • Present an overview of HTTPS (HTTP over SSL). • Present an overview of Secure Electronic Transactions (SET) and Dual Signature.
  3. 3. We cannot enter into alliance with neighboring princes until we are acquainted with their designs. —The Art of War, Sun Tzu
  4. 4. Key points • Secure socket layer (SSL) provides security services between TCP and applications that use TCP. • The Internet standard version is called Transport Layer Security (TLS). • SSL/TLS includes protocol mechanisms to enable two TCP users to determine the security mechanisms and services they will use.
  5. 5. Web Security Considerations • The World Wide Web is fundamentally a client/server application running over the Internet and TCP/IP intranets • The following characteristics of Web usage suggest the need for tailored security tools: • Web servers are relatively easy to configure and manage • Web content is increasingly easy to develop • The underlying software is extraordinarily complex • May hide many potential security flaws • A Web server can be exploited as a launching pad into the corporation’s or agency’s entire computer complex • Casual and untrained (in security matters) users are common clients for Web-based services • Such users are not necessarily aware of the security risks that exist and do not have the tools or knowledge to take effective countermeasures
  6. 6. Table 6.1 A Comparison of Threats on the Web
  7. 7. Tcp/ip protocol stack The advantage of IPSec is that it is transparent to end users and applications and provides a general-purpose solution. IPSec includes a filtering capability so that only selected traffic need incur the overhead of IPSec processing
  8. 8. Tcp/ip protocol stack SSL or TLS also transparent to applications or embedded in specific packages e.g: MS IE browsers come equipped with SSL.
  9. 9. Tcp/ip protocol stack Application-specific security services are embedded within a particular application. The service can be tailored to the specific needs of a given application. E.g. for web is SET.
  10. 10. Secure Sockets Layer (SSL) • One of the most widely used security services • A general purpose service implemented as a set of protocols that rely on TCP • Could be provided as part of the underlying protocol suite and therefore be transparent to applications • Can be embedded in specific packages • e.g. most browsers come equipped with SSL
  11. 11. SSL in ms internet explorer 8
  12. 12. SSL in Mozilla firefox 3
  13. 13. SSL in chrome
  14. 14. SSL Architecture • SSL is designed to make use of TCP to provide a reliable end-to-end secure service. • It is a two layer protocol. Used in the management of SSL exchanges Provides basic security to various higher-layered protocols
  15. 15. SSL Architecture • Two important SSL concepts are: SSL connection • A transport that provides a suitable type of service • For SSL such connections are peer-to-peer relationships • Connections are transient • Every connection is associated with one session SSL session • An association between a client and a server • Created by the Handshake Protocol • Define a set of cryptographic security parameters which can be shared among multiple connections • Are used to avoid the expensive negotiation of new security parameters for each connection
  16. 16. A session state is defined by the following parameters: Session identifier An arbitrary byte sequence chosen by the server to identify an active or resumable session state Peer certificate An X509.v3 certificate of the peer; this element of the state may be null Compression method The algorithm used to compress data prior to encryption Cipher spec Specifies the bulk data encryption algorithm and a hash algorithm used for MAC calculation; also defines cryptographic attributes such as the hash_size Master secret 48-byte secret shared between the client and the server Is resumable A flag indicating whether the session can be used to initiate new connections
  17. 17. A connection state is defined by the following parameters: Server and client random • Byte sequences that are chosen by the server and client for each connection Server write MAC secret • The secret key used in MAC operations on data sent by the server Client write MAC secret Initialization vectors • When a block cipher in CBC mode is used, an initialization vector (IV) is maintained for each key • This field is first initialized by the SSL Handshake Protocol • The final ciphertext block from each record is preserved for use as the IV with the following record Sequence numbers • Each party maintains separate sequence numbers for transmitted and received messages for each connection • When a party sends or receives a change cipher spec message, the appropriate sequence number is set to zero • Sequence numbers may not exceed 264 - 1 • The secret key used in MAC operations on data sent by the client Server write key • The secret encryption key for data encrypted by the server and decrypted by the client Client write key • The symmetric encryption key for data encrypted by the client and decrypted by the server
  18. 18. SSL Record Protocol The SSL Record Protocol provides two services for SSL connections Confidentiality Message integrity The Handshake Protocol defines a shared secret key that is used for conventional encryption of SSL payloads The Handshake Protocol also defines a shared secret key that is used to form a message authentication code (MAC)
  19. 19. The Record Protocol takes an application message to be transmitted, fragments the data into manageable blocks, optionally compresses the data, applies a MAC, encrypts, adds a header, & transmit the resulting unit in a TCP segment. Received data are decrypted, verified, decompressed, & reassembled and then delivered to higher-level users. SEND
  20. 20. SSL Header
  21. 21. Change cipher spec protocol Figure 6.5 SSL Record Protocol Payload • This protocol consists of a single message, which consists of a single byte with the value of 1. • The sole purpose of this message is to cause the pending state to be copied into current state, which updated the cipher suite to be used on this connection.
  22. 22. Alert protocol Figure 6.5 SSL Record Protocol Payload • Used to convey SSL-related alerts to peer entity. • Alert messages are compressed and encrypted, as specified by the current state.
  23. 23. Handshake protocol • The most complex part of SSL. • Allows the server and client to authenticate each other. • Negotiate an encryption, MAC algorithm and cryptographic keys. • Used before any application data is transmitted.
  24. 24. Transport Layer Security (TLS) • An IETF standardization initiative whose goal is to produce an Internet standard version of SSL • Is defined as a Proposed Internet Standard in RFC 5246 • RFC 5246 is very similar to SSLv3 Differences include: • Version number • Message Authentication Code • Pseudorandom function • Alert keys • Cipher suites • Client certificate types • Certificate_verify and Finished Messages • Cryptographic computations • Padding
  25. 25. HTTPS (HTTP over SSL) • Refers to the combination of HTTP and SSL to implement secure communication between a Web browser and a Web server • The HTTPS capability is built into all modern Web browsers • A user of a Web browser will see URL addresses that begin with https:// rather than http:// • If HTTPS is specified, port 443 is used, which invokes SSL • Documented in RFC 2818, HTTP Over TLS • There is no fundamental change in using HTTP over either SSL or TLS and both implementations are referred to as HTTPS • When HTTPS is used, the following elements of the communication are encrypted: • • • • • URL of the requested document Contents of the document Contents of browser forms Cookies sent from browser to server and from server to browser Contents of HTTP header
  26. 26. Connection Initiation For HTTPS, the agent acting as the HTTP client also acts as the TLS client • The client initiates a connection to the server on the appropriate port and then sends the TLS ClientHello to begin the TLS handshake • When the TLS handshake has finished, the client may then initiate the first HTTP request • All HTTP data is to be sent as TLS application data There are three levels of awareness of a connection in HTTPS: • At the HTTP level, an HTTP client requests a connection to an HTTP server by sending a connection request to the next lowest layer • Typically the next lowest layer is TCP, but it may also be TLS/SSL • At the level of TLS, a session is established between a TLS client and a TLS server • This session can support one or more connections at any time • A TLS request to establish a connection begins with the establishment of a TCP connection between the TCP entity on the client side and the TCP entity on the server side
  27. 27. Connection Closure • An HTTP client or server can indicate the closing of a connection by including the line Connection: close in an HTTP record • The closure of an HTTPS connection requires that TLS close the connection with the peer TLS entity on the remote side, which will involve closing the underlying TCP connection • TLS implementations must initiate an exchange of closure alerts before closing a connection • A TLS implementation may, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an “incomplete close” • An unannounced TCP closure could be evidence of some sort of attack so the HTTPS client should issue some sort of security warning when this occurs
  28. 28. Secure electronic transactions (set) • An open encryption and security specification to protect credit card transaction over the Internet. • Companies involved: • MasterCard, Visa, IBM, Microsoft, Netscape, RSA, Terisa and Verisign. • NOT a payment system. • Rather, SET of security protocols and formats to enables users to employ the existing credit card payment infrastructure on an open network, such as the Internet.
  29. 29. Set services • Provides a secure communication channel in a transaction. • Provides trust by the use of X.509v3 digital certificates. • Ensures privacy because the information is only availble to parties in a transaction when and where necessary.
  30. 30. Set participants
  31. 31. Set participants • A cardholder is an authorized holder of a payment card (e.g., MasterCard, Visa) that has been issued by an issuer. • A merchant is a person or organization that has goods or services to sell to the cardholder. • This is a financial institution, such as a bank, that provides the cardholder with the payment card.
  32. 32. Set participants • This is a financial institution that establishes an account with a merchant and processes payment card authorizations and payments. • The acquirer provides authorization to the merchant that a given card account is active and that the proposed purchase does not exceed the credit limit. • The acquirer also provides electronic transfer of payments to the merchant's account.
  33. 33. Set participants • This is a function operated by the acquirer or a designated third party that processes merchant payment messages. • The payment gateway interfaces between SET and the existing bankcard payment networks for authorization and payment functions. • This is an entity that is trusted to issue X.509v3 public-key certificates for cardholders, merchants, and payment gateways. • The success of SET will depend on the existence of a CA infrastructure available for this purpose.
  34. 34. Key features of set • Confidentiality of information: • Cardholder account & payment information is secured as it travels across the network. • It prevents the merchant from learning the cardholder’s credit card number; this is only provided to the issuing bank. • Conventional encryption by DES is used to provide confidentiality.
  35. 35. Key features of set • Integrity of data: • Payment information sent from cardholders to merchants includes order information, personal data, and payment instructions. • SET guarantees that these message contents are not altered in transit. • RSA digital signature (SHA-1 hash codes), provide message integrity. • Certain messages are also protected by HMAC using SHA-1.
  36. 36. Key features of set • Cardholder account authentication: • SET uses X.509v3 digital certificates with RSA signatures for enable merchant to verify that a cardholder is a legitimate user of a valid card account number.
  37. 37. Key features of set • Merchant authentication: • SET enables cardholders to verify that a merchant has a relationship with a financial institution allowing it to accept payment cards. • SET uses X.509v3 digital certificates with RSA signatures a range of applications. Note : SET only provides only one choice for each cryptographic algorithms as SET is a single application witha single set of requirements, whereas IPSec and SSL/TLS are intended to support a range of applications.
  38. 38. Sequence of events for transactions 1. The customer opens an account. 2. The customer receives a certificate. 3. Merchants have their own certificates. 4. The customer places an order. 5. The merchant is verified. 6. The order and payment are sent. 7. The merchant request payment authorization. 8. The merchant confirm the order. 9. The merchant provides the goods or service. 10. The merchant requests payments.
  39. 39. Dual signature Purpose: is to link two messages that are intended for two different recipients. Example: The 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.
  40. 40. Dual signature DS  EKRc [ H ( H ( PI ) || H(OI))]
  41. 41. Payment processing Cardholder sends Purchase Request
  42. 42. Payment processing Merchant Verifies Customer Purchase Request
  43. 43. Payment processing Merchant Authorizes Transaction with Payment Authorization
  44. 44. Payment processing Merchant Requests Payment with Payment Capture
  45. 45. Summary • Web security considerations • Web security threats • Web traffic security approaches • Secure sockets layer • • • • • SSL architecture SSL record protocol Change cipher spec protocol Alert protocol Handshake protocol • HTTPS • Connection initiation • Connection closure • Transport layer security Version number Message authentication code Pseudorandom function Alert codes Cipher suites Client certificate types Certificate_verify and finished messages • Cryptographic computations • Padding • • • • • • • • Secure Electronic Transactions (SET) • Dual Signature