Hi,
I have a website I want to secure, however SSL is no longer an option. I have evidence that a third party is interrupting the SSL handshake and working as a man in the middle.
Any other options? I understand training the employees no to accept invalid certificates would solve this problem, however this isn't an option.
Any ideas? I was thinking about setting up a VPN based on IPSEC might possibly solve this problem, however I believe that IPSEC also uses x509 certificates.
Your insights would be greatly appreciated.
This Question has been solved and asker verified All Experts Exchange premium technology solutions are available to subscription members.
Experts Exchange has been collecting answers to technology questions since 1996…3 million and counting! If you have a question, chances are we already have your answer.
If you can't find the exact answer you're looking for, ask our exclusive community of 50,000 experts. You’ll get a personalized answer from a trusted professional.
Thousands of free tech tips, tricks, how-to’s and tutorials are available in our peer reviewed articles section. See for yourself how smart our experts are, no login required.
Save solutions to your questions, answers you’ve discovered through searching plus helpful articles in your personal knowledgebase for easy future access.
Access the answers to your technology questions today.
30-day free trial. Register in 60 seconds.
Members of the expert community talk about why the experience at Experts Exchange is different than what you will find anywhere else.
Try it out and discover for yourself.
30-day free trial. Register in 60 seconds.
Join the community of experts here and help other tech pros by answering question in your area of expertise. You can earn FREE access to all Experts Exchange's premium features and resources.
It is occurring when an employee in the field connects, from a certain country. I believe they are clicking through the certificates errors. Unfortunately, bad practice has encouraged this behavior. I have my hands tied from investigating further, however need to come up with a solution without any type of support.
No, you aren't screwed. The Man in the Middle attack against SSL relies on providing a fake or a wildcard certificate to the side trying to connect. With an OpenSSH tunnel with a shared key, no opportunity is provided for this to occur. However, the country from which your client is connecting might block off SSH completely. However, you are in the position where you will HAVE to run the VPN from the client to your server, so he needs that software on his laptop. Alternatively, and I know there is a lot said against this, just let him make a normal PPTP VPN connection to you. It's easy to set up and it is not THAT insecure if your make sure that the passwords are of a reasonable length and complexity.
In iis7 it is easy to use common windows authetication, to ensure which users can acces the website, however the data traffic will not be secured/encrypted since this runs on standard http and not https. If you chose this, you can ad a user on the server that is only member of IIs_IUSRS. so that this user will not have acces to the "rest" of the sever...
Not a very safe solution and maybe not very smart, but increadibly easy to implement..
I found a very interesting article on SSH and how id does not need a CA.
http://www.securityfocus.c
Thank you all for your thoughts.
Ok, a few points to make here.
1) SSH isn't normally used for websites (as ifer0x01 says) - it can be used for shell access (and that is what it is commonly used for) but equally, it can be used as a "poor man's vpn" (via the port tunnel functionality) and even a dynamic web proxy (using the socks support)
While SSH "doesn't use a CA", when it comes right down to it, an X509 certificate is just a RSA key (or in unusual cases, a DH/E key) with a "wrapper" around it which consists of some usage flags, some endnode identification strings, and a digital signature to ensure that the rest of the packet has not been tampered with. SSH retains the keys, but discards the certificate, relying on the client remembering which RSA or DH keys it has seen in the past and notifying the user of any changes. This is significantly less than HTTPS X509 offers.
2) X509, in common HTTPS/TLS usage, contains a public key, a endnode identification string (usually the dns name of the endnode), a validity range, a usage flag (restricting what tasks the X509 can be held valid for) and a digital signature from a CA - which is supposed to ensure that a "fake" certificate can be recognised. In fact, usually the digital signature is ALL the CA supplies, the rest coming from the certificate signing request used to buy the certificate. While it is bad that users ignore the warnings, there isn't a serverside fix for that - the only recourse is to fix it clientside by providing (and insisting on) a custom client other than the web browser for users to access the service.
3) most VPNs do not use x509 - while X509 is an option in IPSEC, it is unusual (and the exception) to find it used - most solutions are either preshared key, or challenge-response (classic username+password login, either with a fixed password or some 2-factor token such as the RSA inc or vasco inc solutions). The cisco solution is typically both (a "group" preshared key is used for phase one, and the user+pass validated down an established tunnel as part of phase 2)
4) IPSEC solutions which use X509 almost always have it as an alternative to the PSK or challenge-response - so the certificate is provided *by the client* not the server, and validated by the server, not the client. There is no opportunity therefore for the client to "skip" a warning box, as there is no warning box, just a straight rejection.
5) the new generation of "SSL vpns" are in fact a generic non encrypted VPN run over a X509 secured SSL tunnel. Again, the client is given no opportunity to "accept" a bad certificate, the connection simply fails. The old generation of ssl vpns was, by contrast, more similar to SSH tunnels (in that a localhost port was opened by a java applet and connected to the target down an individual ssl tunnel, then the browser redirected to localhost) but again, the certificate was validated by the java applet and would not permit a bad cert match to be made. The danger here is that usually the applet is downloaded from the very server it then connects to, so a well prepared MITM attacker could simply substitute the applet himself - and in most cases, the applet, if signed, is not signed by a CA issued key but a self-generated one so will generate the very error you wish to avoid the users ignoring, and will *require* the users to ignore that error to continue... So called "thick client" installs lack this problem, but of course then must be pre-installed from a trusted source, and can't be used "on the fly" from a machine having only a browser.
Business Accounts
Answer for Membership
by: stefanxPosted on 2009-09-24 at 08:27:23ID: 25414352
Where do you think the Man-in-the-Middle interception is happening? Is it just before your server, i.e where your site is hosted, or is close to where your visitors are?
If the action is on your server's side, i.e the place where your server is located is doing the interception, then either move your site to a different hosting provider, or, if you can't, consider getting an externally hosted server, run a SSL-based tunnel or VPN between your existing server and the external server relying on shared secret rather than X509 certificates and then proxy for your https webserver via the external server.
If on the other hand, the interception is happening on the client side, like say at a company's firewall, then moving the webserver or running a proxy will make no difference - you will then need a VPN directly from the client to your server to get past this.