Generating a request for an SSL certificate (step 1)
Processing of confidential data – now what?
You might have noticed this many a time: There is a padlock symbol displayed in
the address bar next to the link which in turn starts with
https://.
This is common practice as far as online business and bank transactions, but on
sites that don't handle any confidential data at all this is becoming more
widespread as well, the reasoning here being that it shouldn't be anyone's
business what visitors of said site are doing. Even here on
robidu.de you are going to find this when you are
visiting particular pages on this domain, like this one.
What you are dealing with here is an encrypted and secured connection that
cannot be eavesdropped on on the one hand and is resistant to any attempts to
tamper with it on the other.
In order to attain these traits of an encrypted connection, certificates are
used to provide the necessary keys to encrypt the data sream between your
browser and the server for said web site as well as provide some information on
the visited server. This way you may easily find out what you are dealing with.
Reading along unwanted!
Transactions with businesses or authorities as well as the protection of the
privacy of correspondence (yes, even electronic mail is still mail!) surely are
valid reasons for the application of encryption technologies. Here data is
transferred that is only the user's and maybe a recipient's business and
nobody else's. Unfortunately there are plenty of rapscallions and imbeciles who
see things differently and would rather read along everything – the sense
behind all this has yet to be found – but in the case of definitely
confidential transactions this is definitely objectionable.
In contrast to this one could argue that applying cryptography on sites whose
data isn't confidential but is publicly accessible would be tantamount to
taking a sledgehammer to crack a nut. However, the reasoning that it isn't
anybody's business what any one visitor is doing on such a site cannot be
dismissed, either (keyword privacy), however, the question nevertheless
arises if this is overkill.
Encryption still requires computing time, because the data strem needs to be
encrypted at the sender's side and decrypted at the recipient's side. One could
argue that ever more powerful computers mitigate this delay, but it
nevertheless persists. Furthermore an encrypted connection inevitably call
shady figures into action who in turn attempt to break into the server in
question, because they either suspect confidential data to reside on it that
could be abused to the detriment of others – or they suspect some sort of
control or administration software for the server, for blogs, etc. whose flaws
could be exploited for hacking into the server in question so that it may be
used for some illegal activities.
That's why I decided to secure exactly those areas with cryptography in which
confidential data is transmitted, whereas those in which nothing like that is
taking place remain unencrypted. First of all this site doesn't have to hide,
and secondly there are far greater threats to your privacy than an unencrypted
connection to the 'Net, which is very much linked to ads and other tracking
elements that are incorporated into web sites (which is exactly the reason why
you are never going to find anything like that here).
Self-signed certificate or not?
Both variants have their advantages and disadvantages. A self-signed
certificate doesn't cost you anything, but nevertheless does its job like any
certificate purchased from a certification authority. Its disadvantage is that
it is considered trustworthy in the rarest of cases, and any site that uses a
self-signed certificate that handles confidentialinformation is treated with a
great deal of distrust – especially since a browser is going to notify you
about the problem and advise you against accessing that site. Such a
certificate is nevertheless ideal for testing purposes as well as concealing
the activities of any visitors of your site.
However, when you intend to handle confidential data it is recommended that you
obtain a certificate from a designated certification authority. Depending on
the type of certificate it costs you more or less money, but first of all the
browser won't complain, and secondly the certification authority confirms with
the certificate that the server really is the one it claims to be, although the
simpler certificates don't provide any information about the site's operator.
This normally is available only in the more advanced certificates, but they are
also significantly more expensive.
Domain validation vs. identity validation vs. extended validation
In the simplest case the domain for which the certificate is generated is
verified. This can be done rather easily, especially since the process usually
has been automated and is normally done within one business day.
Things are entirely different with certificates that also confirm the identity
of a site's operator – something that is highly recommended for businesspeople,
because that establishes a much better foundation of trust. However, there
still remains one problem: SSL proxies.
This thing which appears to be harmless at the first glance is in truth a real
ripsnorter: It is able to intercept and decrypt an SSL connection before the
data is reencrypted and transmitted to its intended destination
(you
may read about this on grc.com). In this case many certificates don't help
you any more, because it appears as if you were connected directly to the
desired site without anyone in between, and upon first glance everything
appears to be fine. However, upon closer scrutiny you are quickly going to
notice differences, especially with the digital fingerprints of the
certificates being used. The faked certificate inevitably sports a different
fingerprint than the one from the site being visited, and here
grc.com comes to your aid again. Just enter the
address of the desired server on the page referenced above and compare the
fingerprint that that site has discovered on the site that you are visiting
with the one from the certificate presented to your browser. Should you
discover any discrepancies, the encrypted connection is intercepted by at least
one SSL proxy.
Things are getting much easier in conjunction with the extended validation,
because both Chrome and Firefox are only going to indicate that everything is
all right when the connection is not intercepted. When a certificate that
indicates an extended validation is presented to your browser, it is going to
display a green box to the left of the site's address containig a padlock
symbol instead of only a padlock symbol and in which the holder of the
certificate is mentioned. Since that cannot be forged in either of the two
browsers (both are Open Source so the source code may be reviewed by anyone),
a site with extended validation won't display the green box in case the
connection is being intercepted, because an entirely different certificate is
presented to the browser.
However, it cannot be completely reconstructed how Opera and Safari are going
to behave in this case, because their source codes are not publicly available,
but at the moment it can be assumed that they behave akin to Firefox and
Chrome.
Only the Internet Explorer – once again – stands out negatively, because one
can modify the database of the IE with the aid of a tool in such a fashion that
it presents certificates signed from any certification authority as having been
subject to an extended validation process and hence the indication of the
extended validation is well nigh meaningless.
You may
learn more on this on grc.com again.