How secure is secure Web browsing

TL;DR: In this paper, the root certification authority's (CA's) self-signed certificate is used to verify the security of a secure connection between a web server and a web browser, and the root CA's self-certificate is used for authentication.

Abstract: S ecurity is of particular importance when sensitive information is sent through the Web. Users must rely on the security of the browser's Secure Socket Layer (SSL) protocol. Although the closed-padlock icon in a browser window depicts a secure connection, it does not imply a totally risk-free secure connection. Whenever the padlock is snapped or a security-related message pops up, you should be alerted and scrutinize the security of that connection. During the handshake of a secure connection, the server sends a public-key certificate to identify itself. You assume you have a secure connection to the entity identified in the certificate, but that entity may not be who you think it is. So, what is the critical issue in verifying a server certificate? It is in the root certification authority's (CA's) self-signed certificate that the verification starts. We trust root CAs (assuming they don't issue certificates to copycat servers) because our browser developer trusts them. An initial list of root CA certificates comes with browsers. Depending on their trust in browser developers, users may assume all root CAs that come with browsers are robust. However, authenticity is an important concern for other root CA certificates installed after the browser. An attacker can introduce bogus certificates for installation automated via a Visual Basic script. The client sees only a final approval screen that may easily be ignored by clicking on the \" yes \" button. Consider the following possible scenario. Suppose you've connected to your bank, www.xyzbank.com. Using network-spoofing techniques, an attacker reroutes this traffic to a counterfeit site and imitates a well-known root CA as the issuer for a fake certificate created for xyzbank. The attacker creates a second imitation certificate: a self-signed root CA certificate for the same well-known root CA. When these imitation certificates are used for a secure connection, you, as a client, will see a warning saying the root CA is not to be trusted. Taking a closer look at the certificate details is of no help, even harmful, because your favorite root CA seems to be the issuer. You might easily prefer to continue and maybe install the imitation certificate assuming there is a bug in your system. Because the well-known root CA's name appears on the final approval screen, it is easy to be fooled by this scheme. The only authentication guarantee provided by a closed padlock is that the URL in the certificate …