As I said in the very first post, many developers think that it is very easy to make their software applications secure. One should take a software component that implements the necessary security protocol, plug it to the application and have the application robust, reliable and secure. Though such straightforward approach may work for simple applications, it is very dangerous to use it for securing complex systems. Why dangerous? Because it only gives the illusion of security. You think that your system is secure, while it actually isn’t.
Let’s consider TLS. What can you say about it? TLS is a transport-layer protocol that secures TCP data by encrypting it with robust industry-standard algorithms. A malicious person who intercepts network traffic sees just a sequence of meaningless characters and not the original message.
"Encryption" word sounds like a spell for many people. "If my data is encrypted, no one can read it." Thinking this way is a fatal flaw. No one can read it if the key is in safe place.
Besides encryption, TLS offers a pack of other security services that are often ignored. One of them is server authentication.
Basically, to authenticate someone is to ensure that this someone is the person he pretends to be. When I was ten, I authenticated my friend Michael by three consecutive knocks on the door. The bank guard authenticates the officer by comparing his face to the photo on his PhotoID. Your computer authenticates you by prompting you to provide your account name and password.
In TLS, authentication is performed with the use of digital certificates. Each TLS-capable server has an associated certificate which contains information about its owner, such as host name (or IP address), organization name and its geographic location. Certificates are issued by a trusted insitutions called certification authorities (CA). Three widely used certification authorities are Thawte, Verisign and Comodo.
CA is not required to be a worldwide organization with thousands of employees. To be exact, any person who has a computer can become a CA and issue certificates. However, who will trust them? If my friend Michael told about three secret knocks to everyone, would I consider the knocker to be trusted?
How the authentication is performed? Besides the certificate, the server possesses a corresponding entity called a private key (which can be imagined like a very long binary sequence). Certificate and private key are complementary entities that can be used to perform complementary cryptographic operations. Private key can be used for signing data, while the corresponding certificate can be used for validating the correctness of such signatures. Certificate can be used for data encryption, while only the corresponding private key is able to decrypt data encrypted with such a certificate.
It is obvious that unlike the certificate that is publicly available, the private key must be kept in secret by its possessor.
To authenticate himself to the client, the server uses his private key to sign an arbitrary chunk of data provided by the client. The client then uses server’s certificate to validate the correctness of the signature. As nobody else knows is supposed to know the private key of the server, correctness of the signature ensures that you are talking either to a real server or to someone who has stolen his private key. I do not consider the latter here, this case will be discussed in future posts.
TLS also provides support for client authentication. It works exactly in the same way with the only difference that the client signs the data and the server verifies the correctness of his signature using client’s certificate.
The problem with TLS is that a lot of people who use it think that encryption is its primary feature, while authentication is a secondary one. It is absolutely not correct! There’s no sense in locking the safe if the guard opens it for everyone who asks him about it. If your application does not care about server authentication, it is vulnerable to a dozen of different attacks. One of the most common and easy-to-use attacks based on the lack of authentication is server substitution. Someone just creates a fake server in the network that identifies himself as the original server (there’s a million ways to do this, I omit the exact how-to. Just keep in mind that it is much easier than it might appear at first glance). As no authentication is performed, you will never understand that you are talking to the wrong server. What is worse, the illusion of security is preserved. You are using TLS, so you are secure, aren’t you?
The security of the overall system is defined by the security of its weakest component. There’s no sense in locking the door if the window is open.
Why authentication is often ignored by the developers? I think there are three general reasons for this.
First, authentication is not something one can touch. Encryption is an obvious thing. Authentication is not as transparent as encryption. Besides, 8 persons of 10 consider that “security” is equal to “encryption”.
Second, implementing correct authentication procedure is not an easy task. Some developers (and PM’s/CTO’s as well) consider this task too expensive and do not want to spend a lot of time in implementing it correctly. “Everything works fine without it, so why do we have to postpone the release date of our product for two months for the sake of the feature that no one will have a chance to see?”. Was it a long time ago you’ve heard about 10000 credit card number hijacking the last time? It is likely that their system “worked fine” too.
The third one, the lightmost reason, is the [absolutely reasonable] wish of developer to make the software as much user-friendly as possible. Authentication often requires interaction to the user. Sometimes it is necessary to ask user if he trusts the particular web site or application, sometimes another warning should be displayed. Some developers think that this will bother user. Will not the user be bothered by the stolen password database?
Authentication of the remote is absolutely necessary. The most impenetrable door will provide no help if everyone has a key to unlock it. The most progressive encryption algorithm is worth nothing if you are exchanging encrypted data with a wrong person.
No comments:
Post a Comment