The process starts by the browser requesting a specific form that the server has secured. The server checks the request and sees if it came from a secure communication or not. If not, the server redirects the browser to the secured link (https) and the request is submitted again. Now, since the request is coming from a secure link, it means that the browser wishes to establish a secure communication with the server. The server sends its certificate to the browser and the browser evaluates it. If the certificate has no problems, the browser proceeds with the original process (and the yellow padlock will be displayed).

What is the web certificate?

There are several ways to protect the communication over the Internet and to identify the people and the websites to each other. The X.509v3 certificate is a set of information about the website placed with the web-site's public key in a certificate. This information contains the DNS name of the website, public key, a digest (one way hashing) for this information signed by a certification authority. Once a secure connection is requested by the client to the server, the server sends back the certificate. The client evaluates the certificate and continues the rest of the communication with the server based on this evaluation.

Since a public key is used for this communication over a secure socket layer (SSL) channel, it is usually insured that the communication to the website is secure and encrypted. On the other hand, the certificate insures that the website is not a fake and that it is registered at the certificate authority (which issued the certificate).

What are issues faced with secure sites?


Mixing secure and unsecure contents


Using unsecure contents in a secure site reduce the trust level at the client side of the security of the entire site. When you face the warning message about displaying unsecure contents, you wonder which contents are unsecure and wither they contain sensitive data or not. This content may also expose some information about what you are doing.

Implementing secure process in a secure frame inside unsecure frameset is another issue. This can be experienced with the payment process at some trusted websites. For a novice user who has some knowledge about the security in the Internet, he would stop this process directly and changes into another service provider.

Certificate with weak key

If the key was short (probably shorter than 900 bits), it is vulnerable to attackers break. If a secure website’s key was broken, all the traffic from and to the server would be captured by the attacker. Moreover, the attacker will be able to change the content of the traffic, leaving the user (mostly he is the one affected) with an exposed condition where his sensitive information is vulnerable of being stolen and/or altered to the advantage of the attacker [2].

A recent report stated that the MD5 algorithm, which has been used by most certificate authorities, could be vulnerable. Digital signature produced by this algorithm was supposed to be unique, but some researchers in Berlin were able to produce two messages with one signature using MD5 [1]. If online criminals duplicated the work, they could use their own rogue certificate authority — along with a man-in-the-middle attack — to create virtually undetectable phishing schemes that could collect sensitive information normally protected by SSL encryption, the researchers said.

Websites pretending to be secure

This issue is raised with sites that handle sensitive data improperly. They may do not care about the movement between secure and unsecure pages during some security addicted processes. The problem here is that it is very difficult for the browser to differentiate between sensitive and insensitive data.

How would the attack happen?

Looking at the process of starting the secure communication with the website, there are some breakpoints that could drive the communication into the risky way.

First, the client accesses the normal webpage (mostly without typing https at the URL). The targeted website is supposed to redirect the user to the https page. If the original request was captured by an attacker, he might redirect the user to a fake login form. Here, the attack goes.

If the browser was redirected successfully to the proper https page, it will receive a signed certificate from the server. The browser is supposed to evaluate the certificate and continue the communication based on the result of the evaluation. A possibility of the browser receiving a duplicate certificate from unauthorized authority is a big issue that was discovered recently.

Let us assume that the certificate was received successfully from the right server. Now, we come up with a fact that some certificates might have been hacked by an attacker and that he is monitoring the traffic going in to and out of the server. In this case, the attacker would not only be able to see the exchange of sensitive data clearly, but he also may alter the traffic to his advantage.

 

 

References


[1] Group attacks flaw in browser crypto security http://www.securityfocus.com/news/11541?ref=rss 2009/02/10
[2] Secure sites that are not, http://my.opera.com/yngve/blog/show.dml/382945