Is HTTPS as a way of securing client/server communication "secure enough"?

views:

answers:

+1 Q:

Is HTTPS as a way of securing client/server communication "secure enough"?

Hi,

Application I am developing does some kind of server-side authorization. Communication is done via secure channel (HTTPS in my case, with valid SSL cert). I plan to implement something that will verify if remote server is exactly who he claims to be.

I know that no client-side protection is unbreakable, especially given enough time and knowledge. But, if I implement what I described above, is this security approach "secure enough" to protect data from being tampered with, while in transit, or to prevent man-in-the-middle attacks, and to ensure its validity?

I am considering adding another layer of security around transfered data (by using private/public key pair), but I suspect it might be enough to rely on SSL, without reinventing the wheel.

+2 A:

SSL is secure enough with a valid certificate, but ...

A lot of people don't know that getting an invalid certificate error is something that means "Your data is possibly going to be intercept by someone else". They will just ignore the warning and Man-in-the-middle-attack will still work. Also, some older browser like IE6 might not even show you any warning if the certificate is invalid. The problem in this case would be the user, not the technology used. This means that instead of trying to build an other layer of security you should teach the people who use your application what does it means to get an invalid certificate error and why they should use a modern browser.

HoLyVieR 2010-06-23 12:45:05

In my specific scenario, users are not part of the process (and their almost automatic ignoring of certificate-related warnings), but certificate validity should be determined by client program automatically. Of course, malicious user can hijack that process on client side, but it's much harder to pull than MITM-attack. Does this change story in favour of security?

mr.b 2010-06-23 12:54:25

Using SSL with "real" certs makes the client trust the server. But if you need to establish a server->client trust (control which client can access the server), you should use some kind of authentication. One approach is installing SSL client side certificates in each client/browser or using SSL encryption with user id/password.

Martin Wickman 2010-06-23 13:04:35

When I say people ignore the warning, it's because most people reaction to "An invalid certificate error message" is to simply click "Ignore" or "Proceed". It doesn't have anything to do with have malicious software, it's just about people behavior toward that kind of warning. The software recognize properly the invalid certificate, but the user just choose to ignore the error and continue. This is the only possible problem with SSL, it doesn't have anything to do with the software, it's all about the people using it.

HoLyVieR 2010-06-23 13:04:37

+1 A:

Mr. B, As you mentioned that client is going to validate the server SSL certificate and that users are not part of process, I think you will be just fine validating the server SSL certificate. However, you must take good care of verification process. I've seen several client applications which doesn't verify the certificate well enough. By "well enough" I mean that client should verify - 1) Certifying authority 2) Duration 3) Site issued to One of the app I was pen testing had the bug that it was verifying the "CN" of certificate - which can be spoofed (one could create a bogus certificate with arbitrary CN).

Gaurav Kumar 2010-06-25 03:29:52

Thank you for your valuable input to my question! Can you tell me why verifying duration? That would prevent me from extending certificate on server side, without intervention on client side, right?

mr.b 2010-06-25 10:25:22

Let us assume the server certificate is valid for 2 years (say 2010 to 2012). Assume for a moment that in the year 2013, there had been a private key compromise of this certificate and the owner of the server has revoked the SSL certificate. The client software, if it doesn't validate duration of the certificate, will be trusting a compromised SSL certificate. The duration factor of a certificate helps in reducing the exposure to compromised certificates.

Gaurav Kumar 2010-06-25 11:03:25

Good point. But, it also complicates transition from old to new certificate on the client end, right? Basically, it improves security but complicates deployment, which is a classic security vs simplicity trade-off. Would it be a good idea to limit certificate validity to a one year only? That would decrease risk of compromise even further, no?

mr.b 2010-06-25 13:24:50

Yes, you are right. It is classic security vs simplicity trade-off. If you are using .net framework for your client development, you might be in luck, certificate verifications can/are automatically handled by .net framework and you don't have to worry about handling certificate expiry etc. Based on your threat model/risk assessment, you can tweak the certificate expiry date.

Gaurav Kumar 2010-06-25 14:52:04

ansaurus

tags:

views:

answers:

Is HTTPS as a way of securing client/server communication "secure enough"?

related questions