Abstract

Typically, Internet banking and e-commerce websites are considered to be highly secure, with web mechanisms that implement more foolproof solutions for user authentication, such as client-side digital certificates rather than the user name and password combination in order to ensure the safety of user sensitive data. SSL not only hides sensitive data, but also protects millions of users, especially during online transactions. Securing sensitive data such as user login information, bank account, and credit card details, is one most essential and challenging concerns among e-commerce and banking websites, because such information typically travels across the wire and can be compromised or sniffed easily by executing a couple of offensive attacks such as MITM or session hijacking while data is communicating in clear text format. Hence, this paper addresses the inherent issue of web server security and the process of SSL configuring and implementing in the form of digital certificates over an asp.net website.

SSL (Secure Socket Layer)

Secure Sockets Layer (SSL) is a special security mechanism to encode communications between client (browser) and server (IIS) in order to prevent tampering and eavesdropping of the transmitted delicate data. Generally, the data that travels between browsers and a web server is sent in an un-encrypted format, which leads to data snooping vulnerability. If a hacker somehow manages to intercept traffic being sent between a web server and browser, they can easily reveal that information and exploit our private account. So, SSL ensures the privacy of sensitive data that travels across the wire by keeping it confidential or intact.

It has always been a point of discussion and confliction on which OSI layer the SSL does indeed operate. Some references place the SSL protocol in the session layer, while others say that it works at the transport layer.

SSL indeed is made up of two protocols – one actually operates at the session layer (upper segment) and other works at transport layer (upper segment). That is why one resource states that SSL works at the session layer and the other says it works at the transport later, but technically speaking, SSL operates at the transport layer eventually because packet travelling happens through this layer ultimately.

Want to learn more?? The InfoSec Institute CISSP Training course trains and prepares you to pass the premier security certification, the CISSP. Professionals that hold the CISSP have demonstrated that they have deep knowledge of all 10 Common Body of Knowledge Domains, and have the necessary skills to provide leadership in the creation and operational duties of enterprise wide information security programs.

InfoSec Institute's proprietary CISSP certification courseware materials are always up to date and synchronized with the latest ISC2 exam objectives. Our industry leading course curriculum combined with our award-winning CISSP training provided by expert instructors delivers the platform you need in order to pass the CISSP exam with flying colors. You will leave the InfoSec Institute CISSP Boot Camp with the knowledge and domain expertise to successfully pass the CISSP exam the first time you take it. Some benefits of the CISSP Boot Camp are:

  • Dual Certification - CISSP and ISSEP/ISSMP/ISSAP
  • We have cultivated a strong reputation for getting at the secrets of the CISSP certification exam
  • Our materials are always updated with the latest information on the exam objectives: This is NOT a Common Body of Knowledge review-it is intense, successful preparation for CISSP certification.
  • We focus on preparing you for the CISSP certification exam through drill sessions, review of the entire Common Body of Knowledge, and practical question and answer scenarios, all following a high-energy seminar approach.

SSL in Depth

SSL technology encrypts communication over HTTP on port 443 and it is developed by Netscape and endorsed by a wide range of browsers. SSL implementation does not actually modify the HTTP request. All the encryption and decryption processes are handled by the web server inbuilt SSL software itself. The only difference is that the URL protected by SSL begins with https:// rather than http://. The web server that supports the SSL connection must have an installed X.509 certificate. Since it is developed by Netscape, it is not an open-community protocol or free to use. Hence its specification can’t be modified. So, the open-community version of SSL is TLS (Transport Layer Security), which is more extensible and backward compatible with SSL.

SSL Certificates

With SSL digital certificates, a user can decide whether to trust a website. An SSL certificate typically contains your organization’s digital identity, along with both symmetric and asymmetric keys. Generating, configuring, and installing SSL certificates on a web server is not a part of developer’s job. Such a responsibility in fact comes under website admin provision. Once the SSL certificate is obtained, it is installed onto the webserver hosting the particular website, and visitors can confirm that your website is safe to use and your company is legitimate the moment when they browse your website and view the configured SSL certificate.

Organizations purchase a certificate from a renowned certificate authority (CA) and install it on the web server. The user implicitly trusts the CA and is therefore willing to trust certificate information signed by the CA. The CA retains information about each registered user. However, a certificate does not only ensure the trustworthiness of the server, but also provides safety of online transaction. We can view a particular certificate issued by a CA just by clicking the padlock in the URL, such as:

The certificate itself contains identifying information. It is signed with the CA private key to guarantee that it is authentic and not altered. This private key is also known as SSL key, which is covertly connected with the SSL certificate and should reside securely on your web server. The SSL certificate effectively marries to the SSL key during installation of the certificate to the web server. As the SSL key is only used by the web server which validates that the web server can legitimately use the SSL certificate. A typical certificate known as x.509v3 contains following basic information:

  • Certificate Name, organization & address
  • Serial Number
  • Validate date of Certificate
  • Holder Public key
  • Signature Algorithms
  • Expiry date
  • Thumbprints

There are a couple of CAs such as VeriSign, Thawte, DigiCert and commodo which issue digital certificates in exchange for money. If you don’t want to purchase a certificate from a CA, you can even generate your own self-signed certificate. We can even create a certificate, but browsers only trust certificates that come from an organization on their pre-installed list of trusted CAs, referred to as the Trusted Root CA store. An organization must have to comply with security and authentication standards established by the browsers in order to be added to the Trusted Root CA store. You can have a look at the locally installed certificates via this command or MMC as follows:

netsh http show sslcert

How SSL works

SSL implementation requires a web server accompanied with SSL features and browser. One of most important points to remember is that SSL only imparts security for the connection (communication medium between server and client) but does not indeed offer security for the data once received. This means data are encrypted while being transmitted, but doesn’t secure data once they received. SSL uses public key encryption and provide data encoding, message integrity, server and client authentication.

When a client accesses a website which typically may contain both secured and public segments, the secure portion mandates the user to be authenticated in some fashion. When client goes from a public page to the secure portion, the web server starts SSL and protects this type of communication.

The server then sends a message back to the client, indicating a secure session is established and the client in response sends its security parameters. The server compares those values to its own until it finds a match. The server authenticates to the client by sending it a digital certificate, and if the client decides to trust the server, the process continues, otherwise terminated, and finally a secure communication medium is established.

In some rare conditions, the server can require the client to send over a digital certificate for mutual authentication. The client generates a session key and encrypts it with the server’s public key and sends it across to the server, and now a genuinely secure channel is established, where both ends use that symmetric key to encrypt data back and forth.

Note:
The session ends when the client sends a FIN packet to the server.

The following diagram displays the comprehensive process of mutual authentication of both the server and client to each other, via secure socket layer.

The asymmetric encryption is the basic building block of SSL where the public key is freely distributed to encrypt the message, which can only be decrypted by a corresponding private key. The Secure Socket Layer employs a third party organization, a Certificate Authority (CA), to identify one end or both ends of the transactions. This is in short how it works, as per the aforesaid diagram.

  1. A browser sends a request to connect to the server and ask for a secure page (usually any document).
  2. The web server sends its public key with its signing certificate back to client.
  3. The browser checks whether the certificate was issued by a CA it trusts. The client compares the information in the certificate with the information received from the website and verifies all the details. If so, the browser shows the purity of server certificate by showing a green padlock, and client proceeds.
  4. The browser generates a random symmetric encryption key and then encrypts it to the public key of server. Finally, it sends it to the server, along with the encrypted URL and other encrypted HTTP data.
  5. The web server decrypts the incoming packet using its private key and uses the symmetric key to decrypt the URL and HTTP data that was generated randomly at client side.
  6. Then the requested document from the client along with other data is encrypted with the symmetric key and sent back to browser.
  7. Finally, the browser decrypts the packet using the symmetric key and secure handshaking is established.

SSL Advantage

SSL collectively offers the subsequent advantages as per today’s modern e-commerce scenario.

  • Secure online banking transactions, hides credit card details.
  • Secure system and website logins credentials along with other online exchanges of sensitive information.
  • Secure transfer of files over HTTPS and FTP(s) services.
  • To secure hosting control panel logins and activity like cPanel and Parallels.
  • Secure private network (intranet) based data traffic such as file sharing and database connections.
  • Secure network logins and other network traffic with SSL VPNs.
  • Secure webmail and applications like Exchange server, Office Communications Server, and Outlook.
  • Secure virtualization applications like cloud-based computing platforms.

Final Note

This article illustrates the internal workings of Secure Socket Layer under the .NET prospectus. It describes the algorithm used to encrypted communication over the wire and role of public key/ private key combination in terms of securing sensitive data which transmit across the network. More interestingly, it explains the working of SSL and importance of SSL certificates which are issued from a trusted CA and assist to prove the genuine identity a website. Finally, we have come to an understanding of various advantages of implementing SSL on a website.