Here is the context: I am in the development of the administration website of a public website. The users of the administration website are just few employees of a company and I don’t want to make them use HTTP in order to prevent a man-in-the-middle attack.
If I understand well, using HTTP would allow anyone who has the ability to sniff the packet (internet service provider, a malicious guy « listening » to Wifi signal, ...) to catch the login and password when someone log in to the administration website, right?
I read everywhere to use HTTPS and buy some kind of certificate but I am not willing (unless you give me a good reason) neither to pay for this, nor to get one for free in order just to have a green light on the web browser of my users.
As the title of this question points, I don’t understand if:
The HTTPS certificate is entirely part of the secure communication
channel which means that I would have to choose between HTTP or HTTPS
but nothing between.
or if
The HTTPS certificate is just something added on top of the secure
communication channel to give users some « sense of confidence » by a
trusted third party. Which, in this case, would mean that I can
choose between HTTP (everyone can sniff the packet), HTTPS without a
certificate (secure communication but no green light), HTTPS with a
certificate (secure communication with a green light).
or
Something else.
I really don’t see the point of getting a certificate because if someone, despite all technical difficulties, succeed at putting in place a man-in-the-middle attack between one of my user and my web server, in my perception, it does not seem so much added effort to put in place the same attack between my user and the certificate authority.
I must certainly miss something here, can anyone point me any direction?
Thanks
The certificate is necessary for the communication to be secure. See Wikipedia: Public Key Certificate for more detail. If you don't want to pay for one, you could create a self signed certificate (the process varies depending on the web server you are using) but that would require the user to explicitly accept the certificate (each browser has it's own method of doing this).
That may be ok being that this is an admin section and not publicly accessible, but I would still recommend that you buy a certificate. The hassle of creating a self signed one, along with requiring the users to accept it is not worth the few dollars an ssl certificate costs.
I really don’t see the point of getting a certificate because if
someone, despite all technical difficulties, succeed at putting in
place a man-in-the-middle attack between one of my user and my web
server, in my perception, it does not seem so much added effort to put
in place the same attack between my user and the certificate
authority.
That's not quite how SSL works. Over HTTPS, all communication is encrypted when the browser sends it so even if someone were to sniff it, it would be useless.
Related
Minecraft uses a launcher on to reduce theft of the game: anyone can download without charge, but the user must provide credentials for a premium account to be able to update the game. I want to build a similar launcher (in Ruby) for a project, but I'm having trouble figuring out how to securely send the password over to an HTTP server (written with Sinatra, if it matters). Obviously, putting it as a parameter in a URL is a really bad idea.
Also, I've though about somehow sending it using password fields, but I don't know how they work (I don't usually do HTTP stuff). This is still a possibility.
Shorter summary: In Ruby, I want to send sensitive info over an HTTP request to a Ruby/Sinatra server.
Thanks for reading this!
Using password fields is no help. Not even when sent over POST. They are sent in plaintext, no matter how hard you try to hide them - that's the very nature of http.
You should definitely use TLS over https instead. The stdlib gives you Net::HTTP for that, but you may use any http client that supports https.
If there is money/value involved in this scheme, don't settle for anything less! Inventing your own protocol is
way more work (I admit TLS is not always easy to set up, but still a lot less work)
not secure in 99,9% of the cases
completely broken in the rest of the cases
No, honestly, inventing secure protocols is probably one of the hardest jobs out there. So be lame and stick to the mainstream (https), it will pay off in the end.
Edit:
You asked whether TLS costs money because of the need for a certificate. That's only an issue on the server side, in one-way authenticated TLS only the server needs to present a certificate, so clients connecting to that server will not have to buy such a certificate. If you operate the server, too, however, then you will need such a certificate. If you don't want to spend the money, you may look into hosting that gives you https for free. Heroku offers such a free service that I know of, and I assume there are other providers as well.
As #Len said, use HTTPS, or, if that is not an option, encrypt just the password with:
At the very least, XOR encryption
Maybe DES
Or RSA (total overkill, unless your game is worth the attention of power hackers to try to break your encryption, as RSA is banking and military grade)
You would then distribute a public RSA key with your launcher, the private on your server, and use those to encrypt the password (or, use those to encrypt the symmetrical encryption key).
I'm trying to determine how much of a security risk I'm looking at
when I have rubycas itself running over https, but my actual sites
running under http. the reason I'm faced with this issue is that the
sites are deployed on heroku, which means ssl is either really
expensive or really a pain.
In addition to the login details, i also pass user rolls
(authorization) to each site that is then stored in a session.
Any input is greatly appreciated.
The problem with this approach is that neither the sessionid (url or cookie) nor the exchanged data is encrypted. Therefore the data can be read and manipulated both on the way from the server to the user and on the way from the user to the server.
Even a passive attacker that can just sniff the traffic without being able to manipulate it, can create damage: The attacker can just copy the sessionid into his or her own browser. Public wireless connections often use a transparent proxy, so both the attacker and the victim have the same public ip-address, which makes it difficult for the application to tell them apart.
There is a tool called Firesheep that makes this kind of attack extremely easy.
I use a HTTPS connection without a valid SSL certificate. Is the connection safe? Is the information encrypted?
The connection is encrypted even if the SSL certificate isn't valid (expired, snake-oil, untrusted CA, etc.). The SSL certificate validation just makes sure you're connecting to the folks you think you're connecting to. Encryption doesn't do you any good if the folks decrypting your data are crackers instead of PayPal.
Actually it is possible to establish an encrypted connection between complete strangers without a certificate, using Diffie-Hellman or similar key exchange algorithms.
Alice and Bob agree on a random number x. Alice calculates
xa, where a is a large prime number known only to Alice, and sends that to Bob. Bob calculates xb and sends it to Alice. Alice calculates (xb)a, and Bob calculates (xa)b. Since (xa)b = (xb)a = xab, Alice and Bob now both know the number xab and can use it as an encryption key. The beauty of this is that Bob doesn't know a, Alice doesn't know b, and any eavesdroppers don't know either number (because calculating a from xa, in the case of large numbers, would take years).
As supercat points out, this by itself is still susceptible to a man-in-the-middle attack, and that's why at least one end of the transaction needs to authenticate using a certificate. To be accurate, though, it is not the server that checks this, it's the browser, and most browsers will let the user continue if the certificate is invalid (or possibly even garbage). In that event, the connection will still be considerably more secure than a regular connection. To listen in, you'd need to be able to manipulate IP routing or DNS lookups, and you'd have to set it up before the connection was first made, which is not easy to do.
BTW the keypairs in certificates are not what's used to encrypt actual traffic; they are used to establish a new single-use key for a much faster symmetric cipher (such as DES) which then does the rest of the work.
If there were no verification of SSL certificates, then someone who intercepted a communications channel could capture a request to connect to https://www.acmebank.com, send its own request to www.acmebank.com, and negotiate keys with both acmebank.com and the user. After that, it could receive each morsel of data from the user, decrypt with the user's key, and encrypt with acmebank's key, and do likewise with data from acmebank.com. The net effect would be that neither the user nor acmebank would see anything wrong, but the interceptor would be able to decrypt all of the data between the user and acmebank. The user and the bank will be using different keys to handle their communication, but neither entity will know this. Adding any standard aspect to the protocol to inquire what key is in use wouldn't help, since the interceptor could detect such queries and change the responses appropriately.
SSL prevents a man-in-the-middle attack by requiring the host to send the recipient a copy of the key the host is using, encrypted in a form that an intruder won't be able to fake (unless the intruder can fake CA credentials, at least). If one does not use a CA-issued certificate, there will be little protection against a man-in-the-middle attack, though the encrypted layer would prevent passive or retrospective decryption of session contents (BTW, I wish there were standards for something between unencrypted communication and SSL, for situations where passive or retrospective decryption are the primary threat, but I don't know of any).
Don't bother yourself anymore with invalid ssl certificate. You can now generate free browser valid certificate for your server as easily as you would generate a snakeoil (self-signed, browser invalid) certificate. Go see https://letsencrypt.org/ it's free and open to contributions.
Nope. What you're doing when using HTTPS is telling the browser to connect via a different port (443) whereas normally you connect via (80). Without a certificate, the server would refuse the connection. HTTPS is simply not possible without a certificate. Look here and you'll see a certificate is needed for it to work.
It's possible to establish an encrypted connection, yes, but it would still be possible that you're communicating with a cracked cpmputer instead of the real server. Like that, the cracked computer tells the server that he would be the client, decrypt all the data, store it and send the encrypted data to the client (and tell him he would be the server). So it's just a safe connection if there's no vulnerable point between the server and the client, which no one can guarantee.
I am writing a little app similar to omegle. I have a http server written in Java and a client which is a html document. The main way of communication is by http requests (long polling).
I've implemented some sort of security by using the https protocol and I have a securityid for every client that connects to the server. When the client connects, the server gives it a securityid which the client must always send back when it wants a request.
I am afraid of the man in the middle attack here, do you have any suggestions how I could protect the app from such an attack.
Note that this app is build for theoretical purposes, it won't be ever used for practical reasons so your solutions don't have to be necessarily practical.
HTTPS does not only do encryption, but also authentication of the server. When a client connects, the server shows it has a valid and trustable certificate for its domain. This certificate can not simply be spoofed or replayed by a man-in-the-middle.
Simply enabling HTTPS is not good enough because the web brings too many complications.
For one thing, make sure you set the secure flag on the cookies, or else they can be stolen.
It's also a good idea to ensure users only access the site via typing https://<yourdomain> in the address bar, this is the only way to ensure an HTTPS session is made with a valid certificate. When you type https://<yourdomain>, the browser will refuse to let you on the site unless the server provides a valid certificate for <yourdomain>.
If you just type <yourdomain> without https:// in front, the browser wont care what happens. This has two implications I can think of off the top of my head:
The attacker redirects to some unicode domain with a similar name (ie: looks the same but has a different binary string and is thus a different domain) and then the attacker provides a valid certificate for that domain (since he owns it), the user probably wouldn't notice this...
The attacker could emulate the server but without HTTPS, he would make his own secured connection to the real server and become a cleartext proxy between you and the server, he can now capture all your traffic and do anything he wants because he owns your session.
We currently have a group of web-services exposing interfaces to a variety of different client types and roles.
Background:
Authentication is handled through SSL Client Certificate Verification. This is currently being done in web-service code (not by the HTTP server). We don't want to use any scheme less secure than this. This post is not talking about Authorisation, only Authentication.
The web-services talk both SOAP and REST(JSON) and I'm definitely not interested in starting a discussion about the merits of either approach.
All operations exposed via the web-services are stateless.
My problem is that verifying the client certificate on each requests is very heavyweight, and easily dominates CPU time on the application server. I've already tried seperating the Authentication & Application portions onto different physical servers to reduce load, but that doesn't improve dispatch speed overall - the request still takes a constant time to authenticate, no matter where that is done.
I'd like to try limiting the number of authentications by generating an HTTP cookie (with an associated server-side session) after successful client certificate verification, which when supplied by the client will cause client certificate verification to be skipped (though still talking over SSL). I'd also like to time-limit the sessions, and make the processes as transparent as possible from a client perspective.
My questions:
Is this still as secure? (and how can we optimise for security and pragmatism?)
Are there free implementations of this scheme? (I'm aware of the SiteMinder product by CA)
Given the above, should we continue to do Authentication in-application, or move to in-server ?
generating an HTTP cookie (with an
associated server-side session) after
successful client certificate
verification, which when supplied by
the client will cause client
certificate verification to be skipped
Is this still as secure? (and how can
we optimise for security and
pragmatism?)
It's not quite as secure in theory, because the server can no longer prove to himself that there's not a man-in-the-middle.
When the client was presents a client-side certificate, the server can trust it cryptographically. The client and server should be encrypting and data (well, the session key) based on the client's key. Without a client-side cert, the server can only hope that the client has done a good job of validating the server's certificate (as perceived by the client) and by doing so eliminated the possibility of Mr. MitM.
An out-of-the-box Windows client trusts over 200 root CA certificates. In the absence of a client-side cert, the server ends up trusting by extension.
Here's a nice writeup of what to look for in a packet capture to verify that a client cert is providing defense against MitM:
http://www.carbonwind.net/ISA/ACaseofMITM/ACaseofMITMpart3.htm
Explanation of this type of MitM.
http://www.networkworld.com/community/node/31124
This technique is actually used by some firewall appliances boxes to perform deep inspection into the SSL.
MitM used to seem like a big Mission Impossible-style production that took a lot to pull off. Really though it doesn't take any more than a compromised DNS resolver or router anywhere along the way. There are a lot of little Linksys and Netgear boxes out there in the world and probably two or three of them don't have the latest security updates.
In practice, this seems to be good enough for major financial institutions' sites, although recent evidence suggests that their risk assessment strategies are somewhat less than ideal.
Are there free implementations of this scheme? (I'm aware of the SiteMinder product by CA)
Just a client-side cookie, right? That seems to be a pretty standard part of every web app framework.
Given the above, should we continue to do Authentication in-application, or move to in-server ?
Hardware crypto accelerators (either a SSL proxy front end or an accelerator card) can speed this stuff up dramatically.
Moving the cert validation into the HTTP server might help. You may be doing some duplication in the crypto math anyway.
See if you would benefit from a cheaper algorithm or smaller key size on the client certs.
Once you validate a client cert, you could try caching a hash digest of it (or even the whole thing) for short time. That might save you from having to repeat the signature validations all the way up the chain of trust on every hit.
How often to your clients transact? If the ones making up the bulk of your transactions are hitting you frequently, you may be able to convince them to combine multiple transactions in a single SSL negotiation/authentication. Look into setting the HTTP Keep-Alive header. They may be doing that already to some extent. Perhaps your app is doing client cert validation on every HTTP request/response, or just once at the beginning of each session?
Anyway, those are some ideas, best of luck!