Qwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwerty uiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasd fghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzx cvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmq wertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyui opasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfg hjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcv bnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmrty uiopasdfghjklzxcvbnmqwertyuiopasdghjklzxcvbnmqwertyuiopasdf ghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxc Protocols For Secure vbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmq wertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyui

Online Banking opasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfg hjklzxcvbnmqwertyuiopasdfghjklzxcvbnmrtyuiopasdfghjklzxcvbnm qwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyu iopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfg hjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcv bnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqw ertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiop asdfghjklzxcvbnmrtyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxc vbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmq wertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyui opasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfg hjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcv bnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmrty uiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasd fghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzx Made By : Suveer Malhotra cvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmq wertyuiopasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyui Roll No : 28 opasdfghjklzxcvbnmqwertyuiopasdfghjklzxcvbnmqwertyuiopasdfg hjklzxcvbnmqwertyuiopasdfghjklzxcvbnmrtyuiopasdfghjklzxcvbnm

IT Assignment On

INDEX
S.NO PARTICULARS PAGE NO

1.

HTTPS (Hypertext Transfer Protocol Secure)

3-5

2.

3-D Secure 6-10

3.

SLL (Secure Sockets Layer)

11-15

4. BIBLIOGRAPHY 16

HTTPS
(Hypertext Transfer Protocol Secure)
What Is HTTPS (Hypertext Transfer Protocol Secure)?
Hypertext Transfer Protocol Secure (HTTPS) is a combination of the Hypertext Transfer Protocol (HTTP) with SSL/TLS protocol to provide encrypted communication and secure identification of a network web server. HTTPS connections are often used for payment transactions on the World Wide Web and for sensitive transactions in corporate information systems. HTTPS is a URI scheme that is, aside from the scheme token, syntactically identical to the HTTP scheme used for normal HTTP connections, but which signals the browser to use an added encryption layer of SSL/TLS to protect the traffic. SSL is especially suited for HTTP since it can provide some protection even if only one side of the communication is authenticated. This is the case with HTTP transactions over the Internet, where typically only the server is authenticated (by the client examining the server's certificate). The main idea of HTTPS is to create a secure channel over an insecure network. This ensures reasonable protection from eavesdroppers and man-in-themiddle attacks, provided that adequate cipher suites are used and that the server certificate is verified and trusted. The trust inherent in HTTPS is based on major certificate authorities that come pre-installed in browser software (this is equivalent to saying "I trust certificate authority (e.g. VeriSign/Microsoft/etc.) to tell me whom I should trust").

Therefore an HTTPS connection to a website can be trusted if and only if all of the following are true:
1. The user trusts that their browser software correctly implements HTTPS with correctly pre-installed certificate authorities.

2. The user trusts the certificate authority to vouch only for legitimate websites without misleading names. 3. The website provides a valid certificate, which means it was signed by a trusted authority. 4. The certificate correctly identifies the website (e.g., when the browser visits "https://example", the received certificate is properly for "Example Inc." and not some other entity). 5. Either the intervening hops on the Internet are trustworthy, or the user trusts that the protocol's encryption layer (TLS/SSL) is sufficiently secure against eavesdroppers.

Some Examples of Status Codes:

301 Moved Permanently 302 Found 303 See Other 403 Forbidden 404 Not Found

Encryption of data while transferring it over the internet goes a long way in keeping your information secure on the internet. Using HTTPS Encryption while surfing helps in securing your data when you are using a public Wi-Fi network and gives added protection if you are surfing in a secure network. If you are wondering what the HTTPS protocol means and why everyone says its so important to use whenever possible you have come to the right place. If you dont not want anyone to read any sensitive information like your banking data or Email Inbox, you may want to use HTTPS every time possible. Lets look how HTTPS works and keeps your data secure.

What are The HTTPS and How Does It Secure Your Data?
Normally when we surf the internet, we use the HTTP (hyper text transfer protocol) which is the system that facilitates data transfer and reception over the internet. In many ways, HTTPS is identical to HTTP, because it follows the

same basic protocols. The HTTP or HTTPS client, such as your browser, establishes connection to a server on a standard port. HTTP is insecure and is subject to man-in-the-middle and eavesdropping attacks which can let attackers gain access to website accounts and sensitive information. HTTPS is designed to withstand such attacks and is considered secure against such attacks. There are some differences between HTTP and HTTPS, first one being the default port used. HTTP uses the port 80 where as HTTPS uses port 443. HTTPS works by transmitting normal HTTP interactions through an encrypted system, so that the information cannot be accessed by any party other than the user and end server. In case you are accessing sensitive sites like your banking account or email many websites offer the HTTPS connection to make sure no one can eavesdrop on your data. For e.g. The banking and email sites below offer you secure data transfer.

When should we use HTTPS while surfing?

HTTPS is used at many locations like the log-in pages for banking, forms, corporate log-in pages and other applications like the Email in which data needs to be secure. However, if not implemented properly, HTTPS is vulnerable to security breach. Thus it is extremely important for end users to be wary about accepting questionable certificates and cautious with their personal information while using the Internet. Realizing the importance of keeping your searches private Google Search has implemented a secure version of its search engine which can be accessed by going to https://www.google.com. Anytime you are accessing a secure website you may want to make sure that the certificate is signed by a trusted authority. A detailed and informative post about how to validate certificates would be written soon for our readers to understand how to verify the validity of an SSL certificate. Please check out Security section for more information about How you can make your online experience as well as local computer more secure.

3-D Secure
3-D Secure is an XML-based protocol used as an added layer of security for online credit and debit card transactions. It was developed by Visa to improve the security of Internet payments and offered to customers as the Verified by Visa service. Services based on the protocol have also been adopted by MasterCard, under the name MasterCard SecureCode and JCBInternational as J/Secure. American Express has added SafeKey to UK and Singapore on 8 November 2010.[1] 3-D Secure adds another authentication step for online payments. 3-D Secure should not be confused with the Card Security Code which is a short numeric code that is printed on the card.

Description and basic aspects of the protocol

The basic concept of the protocol is to tie the financial authorization process with an online authentication. This authentication is based on a three domain model (hence the 3-D in the name). The three domains are:

Acquirer Domain (the merchant and the bank to which money is being paid). Issuer Domain (the bank which issued the card being used). Interoperability Domain (the infrastructure provided by the credit card scheme to support the 3-D Secure protocol).

The protocol uses XML messages sent over SSL connections with client authentication (this ensures the authenticity of both peers, the server and the client, using digital certificates). A transaction using Verified by Visa/SecureCode will initiate a redirect to the website of the card issuing bank to authorize the transaction. Each issuer could use any kind of authentication method (the protocol does not cover this) but typically, a password-based method is used, so to effectively buy on the Internet means using a secret password tied to the card. The Verified by Visa protocol recommends the bank's verification page to load in an inline

frame session. In this way, the bank's systems can be held responsible for most security breaches. The main difference between Visa and MasterCard implementations resides in the method to generate the UCAF (Universal Cardholder Authentication Field): MasterCard uses AAV (Accountholder Authentication Value) and Visa uses CAVV (Cardholder Authentication Verification Value).

Implementing the protocol

The specifications are currently at version 1.0.2. Previous versions 0.7 (only used by Visa USA) and 1.0.1 have become redundant and are no longer supported. MasterCard and JCB have adopted version 1.0.2 of the protocol only. In order for a Visa or MasterCard member bank to use the service, the bank has to operate compliant software that supports the latest protocol specifications. Once compliant software is installed, the member bank will perform product integration testing with the payment system server before it rolls out the system. ACS providers In 3-D Secure protocol, ACS (Access Control Server) is on the issuer side (banks). Currently, most banks outsource ACS to a third party. Commonly, the buyer's web browser shows the domain name of the ACS provider, rather than banks' domain name, however this is not required by the protocol. Dependent on the ACS provider, it is possible to specify a bank owned domain name for use by the ACS. MPI providers Each 3-D secure transaction involves two simple internet request/response pairs: VEReq/VERes and PAReq/PARes. Visa and MasterCard don't license merchants for sending requests to their servers. They isolate their servers by licensing software providers which are called MPI (merchant plug-in) providers.

Merchants

The advantage for merchants is the reduction of "unauthorized transaction" chargebacks. The disadvantage for merchants is that they have to purchase MPI to connect to the Visa/MasterCard Directory Server. This is expensive (setup fee, monthly fee and per-transaction fee); at the same time it represents additional revenue for MPI providers. Supporting 3-D Secure is complicated and, at times, creates transaction failures.

Buyers/credit card holders

The main advantage for cardholders is that there is a decreased risk of other people being able to use their payment cards fraudulently on the Internet. In most current implementations of 3-D Secure, the issuing bank or its ACS provider prompts the buyer for a password that is known only to the bank/ACS provider and the buyer. Since the merchant does not know this password and is not responsible for capturing it, it can be used by the issuing bank as evidence that the purchaser is indeed their cardholder. This decreases risk in two ways: 1. Copying card details, either by writing down the numbers on the card itself or by way of modified terminals or ATMs, does not result in the ability to purchase over the Internet because of the additional password, which is not stored on or written on the card. 2. Since the merchant does not capture the password, there is a reduced risk from security incidents at online merchants; while an incident may still result in hackers obtaining other card details, there is no way for them to get the associated password. In spite of the prevalence of password-based implementations, 3-D Secure does not require the use of password authentication, and it is perfectly possible to use it in conjunction withsmart card readers, security tokens and the like. These types of devices may provide a better user experience for customers as they free the purchaser from having to use a secure password. Some issuers are now using such devices as part of the Chip Authentication Program or Dynamic Passcode Authentication schemes. One significant disadvantage is that cardholders may see their browser connect to unfamiliar domain names as a result of some vendors' MPI

implementations and the use of outsourced ACS implementations by issuing banks, which may make it easier to perform phishing attacks on cardholders.

Criticism
Verifiability of site identity
The system involves a pop-up window appearing during the online transaction process, requiring the cardholder to enter a pre-agreed password which their card issuing bank will be able to authenticate. The problem for the cardholder is determining if this pop-up window is really from "your bank", when it could be from a fraudulent website attempting to harvest the cardholder's details. Many of these pop-up windows lack access to the page's security certificate, eliminating a way to confirm the credentials of the window. The "Verified by Visa" system has drawn some criticism,[2] [3] [4] [5] since it is hard for users to differentiate between the legitimate Verified by Visa pop-up window or inline frame, and a fraudulent phishing site. This is because the popup window is served from a domain which is:

Not the site where the user is shopping. Not the card issuing bank Not visa.com or mastercard.com

In some cases, the Verified by Visa system has been mistaken by users for a phishing scam[6] and has itself become the target of some phishing scams[7]. The newer recommendation to use an inline frame (IFrame) instead of a popup has reduced user confusion, at the cost of making it harder for the user to verify that the page is genuine in the first place. As of 2010, most web browsers do not provide a simple way to check the security certificate for the contents of an iframe. Some card issuers also use Activation During Shopping (ADS)[8], in which cardholders who are not registered with the scheme are offered the opportunity of signing up (or forced into signing up) during the purchase process. This will typically take them to a form in which they are expected to confirm their identity by answering security questions which should be known

to their card issuer. Again, this is done within the iframe where they cannot easily verify the site they are providing this information toa cracked site or illegitimate merchant could in this way gather all the details they need to pose as the customer. Cardholders who are unwilling to take the risk of registering their card during a purchase, with the commerce site controlling the browser to some extent, can instead go to their bank's home page on the web in a separate browser window and register from there. When they return to the commerce site and start over they should see that their card is registered. The presence on the password page of the Personal Assurance Message (PAM) that they chose when registering is their confirmation that the page is coming from the bank. This still leaves some possibility of a man-in-the-middle attack if the card holder cannot verify the SSL Server Certificate for the password page. Some commerce sites will devote the full browser page to the authentication rather than using a frame (not necessarily an iFrame, which is a less secure object). In this case the lock icon in the browser should show the identity of either the bank or the operator of the verification site. The cardholder can confirm that this is in the same domain that they visited when registering their card, if it is not the domain of their bank. Mobile browsers present particular problems for 3-D Secure, due to the common lack of certain features such as frames and pop-ups. Even if the merchant has a mobile Web site, unless the issuer is also mobile aware, the authentication pages may fail to render properly, or even at all. In the end, many analysts have concluded that the Activation During Shopping (ADS) protocols invite more risk than they remove and furthermore transfer this increased risk to the consumer. In some cases, 3-D Secure ends up providing little security to the cardholder, and can act as a device to pass liability for fraudulent transactions from the bank or retailer to the cardholder. Legal conditions applied to the 3-D secure service are sometimes worded in a way that makes it difficult for the cardholder to escape liability from fraudulent "cardholder not present" transactions.

SSL
(Secure Sockets Layer)
Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols that provide communication security over the Internet. TLS and SSL encrypt the segments of network connections above the Transport Layer, using asymmetric cryptography for privacy and a keyed message authentication code for message reliability. Several versions of the protocols are in widespread use in applications such as web browsing, electronic mail, Internet faxing, instant messaging and voice-over-IP (VoIP). TLS is an IETF standards track protocol, last updated in RFC 5246 and is based on the earlier SSL specifications developed by Netscape Corporation.

Description
The TLS protocol allows client/server applications to communicate across a network in a way designed to prevent eavesdropping and tampering. A TLS client and server negotiate a stateful connection by using a handshaking procedure. During this handshake, the client and server agree on various parameters used to establish the connection's security.

The handshake begins when a client connects to a TLS-enabled server requesting a secure connection and presents a list of supported CipherSuites (ciphers and hash functions). From this list, the server picks the strongest cipher and hash function that it also supports and notifies the client of the decision.

The server sends back its identification in the form of a digital certificate. The certificate usually contains the server name, the trusted certificate authority (CA) and the server's public encryption key. The client may contact the server that issued the certificate (the trusted CA as above) and confirm the validity of the certificate before proceeding. In order to generate the session keys used for the secure connection, the client encrypts a random number with the server's public key and sends the result to the server. Only the server should be able to decrypt it, with its private key. From the random number, both parties generate key material for encryption and decryption.

This concludes the handshake and begins the secured connection, which is encrypted and decrypted with the key material until the connection closes. If any one of the above steps fails, the TLS handshake fails and the connection is not created.

Applications
In applications design, TLS is usually implemented on top of any of the Transport Layer protocols, encapsulating the application-specific protocols such as HTTP, FTP, SMTP, NNTP andXMPP. Historically it has been used primarily with reliable transport protocols such as the Transmission Control Protocol (TCP). However, it has also been implemented with datagramoriented transport protocols, such as the User Datagram Protocol (UDP) and the Datagram Congestion Control Protocol (DCCP), usage which has been standardized independently using the term Datagram Transport Layer Security (DTLS). A prominent use of TLS is for securing World Wide Web traffic carried by HTTP to form HTTPS. Notable applications are electronic commerce and asset management. Increasingly, theSimple Mail Transfer Protocol (SMTP) is also protected by TLS. These applications use public key certificates to verify the identity of endpoints. TLS can also be used to tunnel an entire network stack to create a VPN, as is the case with OpenVPN. Many vendors now marry TLS's encryption and

authentication capabilities with authorization. There has also been substantial development since the late 1990s in creating client technology outside of the browser to enable support for client/server applications. When compared against traditional IPsec VPN technologies, TLS has some inherent advantages in firewall and NAT traversal that make it easier to administer for large remoteaccess populations. TLS is also a standard method to protect Session Initiation Protocol (SIP) application signaling. TLS can be used to provide authentication and encryption of the SIP signaling associated with VoIP and other SIP-based applications.

Security
TLS has a variety of security measures:

Protection against a downgrade of the protocol to a previous (less secure) version or a weaker cipher suite. Numbering subsequent Application records with a sequence number and using this sequence number in the message authentication codes (MACs). Using a message digest enhanced with a key (so only a key-holder can check the MAC). The HMAC construction used by most TLS cipher suites is specified in RFC 2104 (SSL 3.0 used a different hash-based MAC). The message that ends the handshake ("Finished") sends a hash of all the exchanged handshake messages seen by both parties. The pseudorandom function splits the input data in half and processes each one with a different hashing algorithm (MD5 and SHA-1), then XORs them together to create the MAC. This provides protection even if one of these algorithms is found to be vulnerable. TLS only. SSL 3.0 improved upon SSL 2.0 by adding SHA-1 based ciphers and support for certificate authentication.

From a security standpoint, SSL 3.0 should be considered less desirable than TLS 1.0. The SSL 3.0 cipher suites have a weaker key derivation process; half of the master key that is established is fully dependent on the MD5 hash function, which is not resistant to collisions and is, therefore, not considered secure. Under TLS 1.0, the master key that is established depends on both MD5 and SHA-1 so its derivation process is not currently considered weak. It is for this reason that SSL 3.0 implementations cannot be validated under FIPS 140-2.

A vulnerability of the renegotiation procedure was discovered in August 2009 that can lead to plaintext injection attacks against SSL 3.0 and all current versions of TLS. For example, it allows an attacker who can hijack an https connection to splice their own requests into the beginning of the conversation the client has with the web server. The attacker can't actually decrypt the client-server communication, so it is different from a typical man-in-the-middle attack. A short-term fix is for web servers to stop allowing renegotiation, which typically will not require other changes unless client certificate authentication is used. To fix the vulnerability, a renegotiation indication extension was proposed for TLS. It will require the client and server to include and verify information about previous handshakes in any renegotiation handshakes. When a user doesn't pay attention to their browsers indication that the session is secure (typically a padlock icon), the vulnerability can be turned into a true man-in-the-middle attack. This extension has become a proposed standard and has been assigned the number RFC 5746. The RFC has been implemented in recent OpenSS Land other libraries. There are some attacks against the implementation rather than the protocol itself:

In the earlier implementations, some CAs did not explicitly set basicConstraints CA=FALSE for leaf nodes. As a result, these leaf nodes could sign rogue certificates. In addition, some early software (including IE6 and Konqueror) did not check this field altogether. This can be exploited for man-in-the-middle attack on all potential SSL connections. Some implementations (including older versions of Microsoft Cryptographic API, Network Security Services and GnuTLS) stop reading any characters that follow the null character in the name field of the certificate, which can be exploited to fool the client into reading the certificate as if it were one that came from the authentic site, e.g. paypal.com\0.badguy.com would be mistaken as the site of paypal.com rather than badguy.com. Browsers implemented SSL/TLS protocol version fallback mechanisms for compatibility reasons. The protection offered by the SSL/TLS protocols against a downgrade to a previous version by an active MITM attack can be rendered useless by such mechanisms.

SSL 2.0 is flawed in a variety of ways:

Identical cryptographic keys are used for message authentication and encryption.

SSL 2.0 has a weak MAC construction that uses the MD5 hash function with a secret prefix, making it vulnerable to length extension attacks. SSL 2.0 does not have any protection for the handshake, meaning a man-inthe-middle downgrade attack can go undetected. SSL 2.0 uses the TCP connection close to indicate the end of data. This means that truncation attacks are possible: the attacker simply forges a TCP FIN, leaving the recipient unaware of an illegitimate end of data message (SSL 3.0 fixes this problem by having an explicit closure alert). SSL 2.0 assumes a single service and a fixed domain certificate, which clashes with the standard feature of virtual hosting in Web servers. This means that most websites are practically impaired from using SSL. TLS/SNI fixes this and has been deployed in all common Web servers except IIS.

SSL 2.0 is disabled by default in Internet Explorer 7, Mozilla Firefox 2, Mozilla Firefox 3, Mozilla Firefox 4 Opera and Safari. After it sends a TLS ClientHello, if Mozilla Firefox finds that the server is unable to complete the handshake, it will attempt to fall back to using SSL 3.0 with an SSL 3.0 ClientHello in SSL 2.0 format to maximize the likelihood of successfully handshaking with older servers. Support for SSL 2.0 (and weak 40-bit and 56-bit ciphers) has been removed completely from Opera as of version 9.5 Modifications to the original protocols, like False Start (adopted and enabled by Google Chrome) or Snap Start, have been reported to introduce limited TLS protocol version rollback attacks or to allow modifications to the cipher suite list sent by the client to the server (an attacker may be able influence the cipher suite selection in an attempt to downgrade the cipher suite strength, to use either a weaker symmetric encryption algorithm or a weaker key exchange).

BIBLIOGRAPHY
Wikipedia Google Banksviewer.net