This is a guest post written by David Ritchie.
As the World Wide Web takes on more and more enormous importance in our modern life, the security issues become of the most immediate interest now. The risk of personal information pilfering is constantly increasing. In this regard, such terms as antiviruses and brandmauers are no more strange being widely used. Most people realize that private data such as personal correspondence, account details, passport and phone numbers should be transmitted via secured connection to eliminate or, at least, reduce the loss of valuable information. This article is concerned with HTTPS constituting one of the most popular protocols for ensuring data transmission security.
Our intention is to give you an up-close look at HTTPS. The article is structured as follows: Firstly, we will pay attention to HTTPS functional method. The HyperText Protocol Secure provides a safe channel for confidential information exchange. The principle of operation lies in data cryptography and authentication validation.
Secondly, we will consider SSL and TSL cryptographic protocols which ensure communication security over the Internet. Our goal is to define the basic features and primary tasks of SSL and TLS cryptographic protocols. In addition, we will state the main differences of both protocols in order to understand their functionalities better.
Finally, we will shed the light on the issue of HTTPS security improvement. Beyond a doubt, it is the task of the first priority with the increasing volume of online transactions. The activity of Certification Authorities requires urgent regulation. In fact, the system of digital certificates is imperfect to a certain extent. Therefore, we will provide several suggestions on how to improve the HTTPS security at present. The theme of our article is very topical as violate data capture is a frequent operation now. And such fraudulent behavior will, certainly, lead to a range of catastrophic consequences in the e-business sphere if no relevant measures are initiated in the nearest future.
But Get Started with a General Background
HTTPS is referred to as Hypertext Transfer Protocol Secure, being the HTTP extension with crypto operation capabilities. The main principle behind is in transmitting data, “packed” in SSL or TSL cryptographic protocols to ensure security. Stated differently, HTTPS is a secure channel used in the network for data transfer. TCP port 443 is set by default to make a connection. The system was developed by the Netscape Communications Corporations in 2000 with the aim of providing identity verification and secured communications. Truth be told, it will be no trouble to leak any intelligible data circulating over the network. There exist a lot of sniffer programs which allow grabbing all of the computer traffic incoming and outgoing provided the Internet connection is active. It may be e-mails, passwords, payment details and other crucial data hunted for by frauds. However, if the traffic is encrypted, nobody will be able to get access to your data as it is practically impossible to find 128 bit (setting aside 256 bit) encryption key. Therefore, safe banks, reputable payment systems, reliable webmail services, and even some social networking services offer the opportunity of setting a secured connection based on HTTPS. Currently HTTPS is supported by the most popular browsers.
How HTTPS Works
In fact, HTTPS is not a separate protocol, but a common HTTP operating via SSL (Secure Socket Layer) and TLS (Transport Layer Security) encryption mechanisms. Both protocols provide an adequate security from sniffer and man-in-the-middle attacks if the server certificate is reliable and verified, and corresponding cipher suites are applied. The HTTPS protocol usage for sending messages provides authentication validation of those users, who seek access to message queue via web-server as well as allows setting up the secured connection based on SSL between a sender and a receiver. A sender is always regarded as a SSL client, and a receiver – a SSL server, irrespective of whether a message queue server or client software runs at the PC. It should be noted that authentication validation at SSL session setup does not check with message authentication to prove the message correctness and the sender’s identity. In order to prepare a web-server for processing HTTPS, an administrator should get and set up a certificate for this web-server. HTTPS authentication uses two types of certificates, provided by the Certificate Authority on a payable basis:
- Server certificates. These are the keys created by means of encryption. They are the ciphered text elements used to ensure secure connection among the group of users.
- Client certificates. The personal information regarding a user is stated in these certificated ensuring the identification of a SSL client to a server.
However, some web resources apply own certificates. Actually, there is a possibility to prepare such certificates without referring to the Certificate Authority. They are called the self-signed certificates and considered to be less reliable if compared to server and client ones. In this article we are more interested in server and client certificates, being really common nowadays, so let us consider them in great detail.
So, we will start with server certificates. Before setting up a SSL connection for sending messages, a receiving computer requests a server certificate. A server certificate, provided by the Certification Authority, could be issued to the name of NetBIOS or full computer DNS name. Nevertheless, while sending HTTPS messages, a transfer target, stated in the message, should be identical to the computer name in the receiver’s server certificate. Thus, the authentication validation is not completed, when only NetBIOS transfer target (for instance, with direct format name DIRECT=HTTPS://msmqserv/msmq/private$/q1) is used for sending messages within the same intranet forest to a computer with only full DNS name. Consequently, when a message queue tries to prepare a SSL session, an alert appears that the name in the certificate does not correspond to the transfer target, and messages, sent in this manner, are collected in the outgoing messages queue.
Special mention must be made of server certificate validation on the sender’s computer. IIS service for the part of a receiver should send the server certificate to a sender for authentication validation. The server certificate, containing the Certification Authority signature, the public key of a sender, some supplemental information about a receiver and a validity date, should be received from a Certification Authority which guarantees that a certificate owner is verified. Each certificate contains two keys: a public and a private. The public key is used for traffic encryption, and the private key is used for de-encrypting the traffic received from the client. In order to perform the authentication validity, it is necessary to prove two-way trust relationship by means of a signed certificate.
The next part of our article refers to client certificates. SSL sessions might require an additional security component if IIS server at a receiver’s computer requests a sender’s client certificate for authentication validation. The client certificate is provided by the Certificate Authority a trust relationship is established with. In general, client certificates mapping is a basis of authentication validation. After web-resource set-up in accordance with SSL channel request, a security fetch protection is still a must. If you run client certificates it will be possible to prepare maps to protect the content. Therefore, data stated in the client certificate will be mapped with a user account. The mapping process is flexible. Both, mapping of separate client certificates with user accounts as well as “many to one mapping”, where a wide range of certificates meeting the specific criteria, are available. After mapping it is possible to limit or enable access to a virtual catalogue, setting up the security parameters for a corresponding physical catalogue. If all conditions set by IIS server are met, a sender (SSL client) and a receiver (SSL server) create and exchange SSL session keys. As it was mentioned above, these keys are used for encryption and de-encryption of all packages transferred via SSL connection.
Let us just recap briefly on access control via HTTPS. There exist two layers of authentication validation. The first one is authentication between jumps. It is performed in the net between jumps with the ISAPI (mqis.dll), filter, set up at the target IIS server. The second one is end-to-end authentication which is based on public key certificates and combined with Session Initiation Protocol (SIP) used to authenticate the sender of SIP request message.
SSL and TLS
SSL (Secure Sockets Layer) is a cryptographic protocol providing the secure connection between a client and a server. SSL was initially developed by the Netscape Communication Corporation. Thereafter, the RFC standard, called TLS, was generated and accepted on the basis of SSL 3.0. The protocol ensures data exchange privacy between a client and a server, which applies TCP/IP with a public key asymmetric algorithm used for encryption process. As a matter of fact, a public key cryptography is based upon the usage of two different keys (public and private) instead of one. Hence, if one key is used for encryption, consequently, the other one is required for decryption. In this situation, there exists the possibility to receive secure messages, stating a public key, and keeping the private one under wraps.
The SSL protocol consists of two sub protocols, i.e. a SSL Record protocol and a SSL Handshake protocol. The former one defines a data transmission format. The SSL protocol includes a handshake with SSL Record protocol to provide message series exchange between a server and a client at first connection. The SSL protocol constitutes a secure channel with three basic features:
- The channel is secure. Encryption is applied for all messages after a simple dialogue to define a private key.
- The channel is authenticated. The server part of the dialogue is urgently authenticated whereas authentication is optional for a client part.
- The channel is reliable. The transportation network includes the integrity checking with MAC.
It stands to mention that SSL not only provides data safety in the World Wide Web, but also performs server and client authentication. The primary objectives of the SSL protocol are as follows:
- Cryptographic security. SSL protocol provides private and reliable method of information sharing between two applications which communicate remotely.
- Consistency. Programmers, independently of each other, could generate applications which use SSL to guarantee successful exchange of cryptographic parameters without identifying a code of another program.
- Program – platform independence. The SSL protocol was developed on the principle of transferability so that its processing ideology does not depend upon the applications within the framework of which it is used.
- Expandability. The SSL protocol provides environment to include new public keys as well as sophisticated encryption techniques if necessary.
- Efficiency. The high rate of a central processing unit is required for SSL operation, in particular while working with public keys. Nevertheless, the SSL protocol remains one of the most efficient solutions to the problem of user data protection while transferring them over an “open” channel.
The SSL protocol supports three types of authentication validation: client and server authentication, server authentication with unauthenticated client, and full anonymity. Whenever server is authenticated, the channel is considered safety against data capture between a web-server and a browser. However, a completely anonymous session is, actually, open to attacks. An anonymous server could not identify a client. Being authenticated, a server provides a true certification chain to the Certificate Authority. Put it differently, an authenticated client should provide an adequate certificate for a server. Each party is responsible for controlling the validity interval of other party’s certificate. The main goal of key exchange is creation premaster secret known only to a client and a server. This premaster secret is used for generating a master secret required for encryption keys, a message authentication code, a finished message to encrypt data afterwards.
To be fair, we should point out that the SSL protocol could guarantee the complete safety of any Internet connection provided that all software tools implementing the SSL technology are faultless. But frequently, this is far from being the case. On the other part, the invention of cryptographic private/public algorithm is the most important cornerstone in the modern world of booming e-commerce.
Let us continue with TLS being the outcome of IETF (Internet Engineering Task Force) initiative. The TLS (Transport Layer Security) protocol was being developed on the basis of SSL 3.0 specification from the Netscape Company. The main function of the TLS protocol lies in providing safety and data integrity between two communicating applications: a client and a server. The basic tasks of TLS are identical to those of SSLv3, in particular, cryptographic security, consistency, expandability and efficiency. So, we will not touch on them even briefly. We would like to pay your attention to TLS two layers: the Record Protocol and the Handshake Protocol. The former one is based upon connection confidentiality and integrity. It is used for encapsulating higher level protocols. The Handshake protocol is one of them. It allows a server and a client authenticating each other. The difference between SSLv3 and TLS is not significant so that we will not go into details and specify just basic characteristics. Firstly, we should make an important point that TLS 1.0 and SSL 3.0 are incompatible. And the main differences are listed below:
- MAC identification schemes differ by two parameters, in particular, an applied algorithm and the data area, for which a message authentication code is identified.
- PRF function is used in TLS. This function ensures the receipt of short secret key used for generating longer data units (based on HMAC algorithm with specific data extension scheme), protected against to functions of hashing and identifying a message authentication key. A secret key results from the usage of the same data extension scheme , but with MD5 or SHA algorithm.
- “No certificate” alert is not applied in TLS.
- All algorithms of symmetric encryption schemes exclusive of Fortezza are included in TLS.
- A “finished” message in TLS constitutes a hash code identified with master secret. The scheme of identification is different if compared with SSL.
- Master secret identification scheme in TLS differs from SSLv3 scheme.
- In TLS it is possible to add any number of fillers (up to 255 bytes) provided that the data unit length is a multiple of the cipher unit length.
Despite all difference both protocols pursue the same goal that is secure data transfer in the net.
Is HTTPS Secure Enough and Are There Ways to Improve Its Security?
All web resources which are protected with HTTPS are considered to be a lot more reliable and safe when compared to a simple HTTP. But how secure is HTTPS? Unfortunately, the frequency of attacks meant to break HTTPS is increasing today. And a good rule of thumb states that there are several successful attempts. The most vulnerable spot of HTTPS is, certainly, the mechanism of authentication. Currently there are three types of digital certificates, and each of them ensures certain validation of sender’s identity:
- Domain-validated certificates. They confirm only the name of a sender. When a recipient does not know the owner of the domain name and does not trust him or her, the level of security is not high.
- Organization-validated certificates. They require validation of the official title and the domain name of the organization. The Certification Authority checks the official title by requesting copies of paper documents, for instance, a founders agreement.
- Extended-validated certificates. The Certification Authority must ensure compliance with severe checking requirements.
It should be mentioned that the major Certification Authorities are VerySign, StartCom, Comodo, and GlobalSign. But do remember that there are hundreds of root and mediatory authorities, so that it is very difficult to define which one is trustworthy and which one is not. So, if proceeded from the premise that there exist a good many Certification Authorities eligible to sell certificates, then a fraud might find just one of them to break into. If successful, the consequences could be really pitiful. As a matter of fact, most attacks are dedicated to domain validation breaking. The most common ways are to crack a router near a Certification Authority or a target web resource. This will allow a breaker to see incoming and outgoing DNS responses. A lot of downgrade attacks are launched to achieve this goal. One more way to obtain private information is to hack BGP or TCP network protocols. This type of the attack provides easy access to e-mail messages. And the last, but not the least is the activity of certain governmental bodies which are entitled to exert influence on a Certification Authority. In other words, there exists a possibility of making a Certification Authority provide a malicious certificate for any domain. To sum up, we would like to point out that currently there are some ways to break HTTPS (inclusive of SSL and TSL protocols) that might have really catastrophic results for a victim.
And, nowadays the developers of the most popular browsers realize in full the feasibility of such malicious attacks. Therefore, they do their best in order to improve the security of HTTPS in the World Wide Web. The attempts of traffic interception must be brought to a stop. Otherwise, the degree of confidence on the part of users will be negated, and the essential top quality servicing will be open to question. In this regard, the developers of the popular browsers give raise to an alarm.
One of the most efficient variants to improve the security of HTTPS provided by the Google Company is to stop using certificate online checking with CRL and OCSP in Chrome browser. The practice is considered to be inefficient when trusted Certification Authority is unavailable, for instance, while performing web authentication at public wireless networks. Simply because under such circumstances most browsers accept the certificate as a valid one, allowing hackers to get around the certificate online checking. It is far better to update the Certificate Revocation List from time to time.
The Mozilla representatives take every care in order to divest the external parties of the provided secondary root certificates. This intention assumes strengthening the control over the whole procedure of certificates provision. Therefore, the thorough regulation of authentication mechanism is one of the most efficient methods intended for HTTPS security improvement.
The Internet Engineering Task Force Community is also concerned with the problem of network security provision. They try to implement the method of fraud detection by generating complex private and public keys for checking the validity of SSL certificates. Thanks to this technology, the possibility to prepare fraudulent SSL certificates could be brought to naught. In any case, the infrastructure of public keys must be upgraded. Otherwise, clever hackers keep generating not genuine certificates which could be used for information pilfering.
No doubt, the Internet security is a topical issue. And one of the problems which are also worth mentioning lies in the usage of old browsers without the required option of encryption support. And the protocols of certificate cancellation and authentication validation are realized not on an adequate level. Frequently a lot of users ignore the warning messages concerning certificate revocation list for a variety of reasons particularly but not exclusively because of ignorance of possible risks. In addition, there are browsers which do not identify the certificates from certain Certification Authorities, and a user does not understand that certificate revocation constitutes any problem. Therefore, top quality software is also a key stone to better security. Despite automated mechanisms of fraudulent certificate cancellation, the function of certificate validity checking is not realized by default in all browsers. As a rule, Certification Authorities recall the stolen certificates quickly enough after theft finding, but the developers of the browsers do not immediately update the list.
So, it’s high time to think over heavier regulation and more thorough audit of Certification Authorities as well as over the implementation of new check levels.
In this article we considered the HTTPS as the most popular method of information protection in the World Wide Web, and how to improve the security of HTTPS. We cannot emphasize enough the importance of transmitting data via a secure channel today when the majority of financial transactions are carried out over the Internet. SSL/TLS cryptographic protocols are integrated in most browsers and web servers to ensure secure connection for transmitting private data. Moreover, we touched upon several points connected with feasible attacks meant to violate data capture. As a matter of fact, hackers exert every effort to crack the above mentioned protocols with the aim of acquiring an easy access to the required information. Under such circumstances the regulation of operations performed by Certification Authorities constitutes one of the most efficient ways of Internet security improvement. And the last paragraph of our article is devoted specifically to the problem of authentication mechanism based on certificate provision. On the whole, the system of digital certificates requires considerable improvements. Otherwise, hackers keep up attacking the Certification Authorities, endangering the network infrastructure as well as the possibility of confidence building in the communication technologies.
This guest article is by David Ritchie. David is a software developer and technical writer with over a decade of professional experience. He works for the rip DVD company and is currently interested in DVD ripping software reviews.