Quite simply, what is the criteria a website must meet for it to need SSL certificate?
Website is not ecommerce but will take user information, contact details and event information.
Even if not technically required does SSL just provide users with added 'trust' in the site?
Cheers
Use SSL when you are collecting sensitive information from your users, which (IMO) includes contact details. Personally I try and avoid submitting personal details about myself over an unencrypted channel.
In the end it's a judgement call. However, if you're collecting addresses, phone numbers, bank details, or anything that can be physically traced back to the user I'd recommend using SSL.
Obviously this only applies if your transport method is insecure (which the Internet, by definition, is). If you're running your website over an already-secure channel (like an internal network, where you trust your users, then there's not much point).
However, if you do decide to use SSL, make sure you get a valid, signed certificate! SSL without a signed certificate is kind of pointless, since it means your end users cannot trust the authenticity of the certificate. This unfortunately costs money, which is why many small websites don't bother.
SSL is all about trust - the certificates are signed by a "trusted" authority, so users can be sure that they are dealing with the proper certificate holders (as opposed to someone performing a man-in-the-middle attack). Obviously this trust is not ultimate - but it's an added step to providing a safe data channel for user information.
I would want to use SSL for any area of any website where personal information is being transmitted e.g. Login, Registration, Account Settings, Contact Details, User Information.
Take a look at the data being shown and ask yourself if you would want to leave that information posted around about you without any protection - go from there.
Whenever you cannot trust the wire - Whenever there is a chance of somebody snooping in to whatever is being sent over the wire (network hub, MITM vulnerability etc.) and whatever is being sent on the wire may contain stuff which at least a small subsection of your customer base will not like anyone to have access to.
Interestingly, SSL combines two components of security, they are:
Encryption
Identification
Encryption
Typically people use SSL because it encrypts the sending of data to the server. This is important if you are taking passwords, but critically important if you are taking credit card information. For this purpose, generally people have SSL for only that page. This isn't perfect, because the non-secure page you land at may have been spoofed, hence your already at the wrong site, so it doesn't really matter if it's encrypted.
Which brings us to ...
Identification
The identification component of SSL is also interesting. PayPal, for example, like their certificates because it is supposed to "prove" that PayPal bought it. Sadly, users don't care or notice this, despite some improvements in browser UI's.
Rarely is it necessary, or worthwhile, to get a certificate for identification (of the server), and IMHO, the two components of SSL should be separated (but that's another story :p). But some may argue that it is useful. I'm not one of those people.
Related
I am creating a chat service program that follows the server/client paradigm. That chat program exists as both a chat server and a chat client, and a user can either host the chatroom(and it will connect his client to that server), or he can join an existing one.
Clients connect via a direct IP address that the other user will tell them, such as gained from whatismyip.com, and a specified port number.
During any time in this chat program, one user can send a file to another user. This is initiated by asking the server to set up a handshake between the two users, with user A passing his IP through the server to user B, and user B calling the new service that user A created for file transfer. This eliminates the original chat server, and the users are connected via a direct IP using nettcp protocol.
Over this file transfer, the files are encrypted with AES after initially sending the AES private key via RSA encryption.
I want to know what kind of ways somebody can initiate a man in the middle attack here. Obviously I see the flaw I have in passing the IP address through the server to the other user, but right now I don't see any other way as I cannot have the server retrieve the IPV4 of the sender.
Is the way a man in the middle attack works, is that he can see that these two users are transferring files, and somehow pull the data stream to himself from both ends? Can he do this on an already ongoing file transfer session?
I'm trying to understand the way MITM attacks work so I can see if I can protect my program from such attacks... but if the only way to reliably do so is to use a certificate authority(of which I'm still learning about), please go ahead and tell me that.
After doing more searching, I found this great link explaining the different types of MITM attacks and how they work and are executed in great detail.
http://www.windowsecurity.com/articles/Understanding-Man-in-the-Middle-Attacks-ARP-Part1.html
There are a total of four parts.
Is the way a man in the middle attack works, is that he can see that
these two users are transferring files, and somehow pull the data
stream to himself from both ends? Can he do this on an already ongoing
file transfer session?
You need to define a threat model. The usual suspects are message insertion, deletion, tampering and reordering. Sometimes the attacker only needs to tamper with a message so you do the wrong thing. For example, he/she may need to flip a bit so "transfer $100 from A to B" changes to "transfer $900 from A to B". In this case, the attacker did not need to be in the middle or decrypt the message.
I'm trying to understand the way MITM attacks work so I can see if I
can protect my program from such attacks... but if the only way to
reliably do so is to use a certificate authority(of which I'm still
learning about), please go ahead and tell me that.
Rather than attempting to design a hardened protocol, perhaps you could use a protocol that already exists that addresses your concerns.
That protocol would be Z-Real-time Transport Protocol (ZRTP). The protocol is specified in RFC 6189, ZRTP: Media Path Key Agreement for Unicast Secure RTP.
ZRTP is a key exchange protocol that includes Short Authentication Strings (SAS) to keep out the MitM. Essentially, the SAS is a voice authentication that only needs to be performed once. You can omit the SAS check, though its not recommended. If you omit the check and the bad guy is not attacking, then everything is OK for current and future sessions.
Once you establish your first secure channel without adversarial tampering, all future sessions will be secure because of the way key agreement for the current session depends on earlier sessions. And the earliest session (first session) is known to be secure.
ZRTP also provides forward secrecy, so a compromise of the current session does not affect security of past sessions.
ZRTP does not require certification authorities or other (un)trusted third parties.
Dr. Matthew Green has a blog about ZRTP on his Cryptography Engineering site at Let's talk about ZRTP.
To answer your question about MitM, there's too much for a Stack Overflow answer. A great free book is Peter Guttman's Engineering Security. MitM is sometimes a goal of an attacker, but it not his/her only vector. Guttman's book looks at a number of threats, how humans act and react, why the attackers succeed, and how to design around many of the problems.
Ok Advanced SSL gals and guys - I'll be adding a bounty to this after the two-day period as I think it's a complex subject that deserves a reward for anyone who thoughtfully answers.
Some of the assumptions here are simply that: assumptions, or more precisely hopeful guesses. Consider this a brain-teaser, simply saying 'This isn't possible' is missing the point.
Alternative and partial solutions are welcome, personal experience if you've done something 'similar'. I want to learn something from this even if my entire plan is flawed.
Here's the scenario:
I'm developing on an embedded Linux system and want its web server to be able to serve out-of-the-box, no-hassle SSL. Here's the design criteria I'm aiming for:
Must Haves:
I can't have the user add my homegrown CA certificate to their browser
I can't have the user add a statically generated (at mfg time) self-signed certificate to their browser
I can't have the user add a dynamically generated (at boot time) self-signed certificate to their browser.
I can't default to HTTP and have an enable/disable toggle for SSL. It must be SSL.
Both the embedded box and the web browser client may or may not have internet access so must be assumed to function correctly without internet access. The only root CAs we can rely on are the ones shipped with operating system or the browser. Lets pretend that that list is 'basically' the same across browsers and operating systems - i.e. we'll have a ~90% success rate if we rely on them.
I cannot use a fly-by-night operation i.e. 'Fast Eddie's SSL Certificate Clearing House -- with prices this low our servers MUST be hacked!'
Nice to Haves:
I don't want the user warned that the certificate's hostname doesn't match the hostname in the browser. I consider this a nice-to-have because it may be impossible.
Do not want:
I don't want to ship the same set of static keys for each box. Kind of implied by the 'can't' list, but I know the risk.
Yes Yes, I know..
I can and do provide a mechanism for the user to upload their own cert/key but I consider this 'advanced mode' and out of scope of this question. If the user is advanced enough to have their own internal CA or purchase keys then they're awesome and I love them.
Thinking Cap Time
My experience with SSL has been generating cert/keys to be signed by 'real' root, as well as stepping up my game a little bit with making my own internal CA, distributing internally 'self-signed' certs. I know you can chain certificates, but I'm not sure what the order of operations is. i.e. Does the browser 'walk up' the chain see a valid root CA and see that as a valid certificate - or do you need to have verification at every level?
I ran across the description of intermediate certificate authority which got me thinking about potential solutions. I may have gone from 'the simple solution' to 'nightmare mode', but would it be possible to:
Crazy Idea #1
Get an intermediate certificate authority cert signed by a 'real' CA. ( ICA-1 )
ROOT_CA -> ICA-1
This certificate would be used at manufacturing time to generate a unique passwordless sub-intermediate certificate authority pair per box.
ICA-1 -> ICA-2
Use ICA-2 to generate a unique server cert/key. The caveat here is, can you generate a key/pair for an IP (and not a DNS name?)? i.e. A potential use-case for this would be the user connects to the box initially via http, and then redirects the client to the SSL service using the IP in the redirect URL (so that the browser won't complain about mismatches). This could be the card that brings the house down. Since the SSL connection has to be established before any redirects can happen, I can see that also being a problem. But, if that all worked magically
Could I then use the ICA-2 to generate new cert/key pairs any time the box changes IP so that when the web server comes back up it's always got a 'valid' key chain.
ICA-2 -> SP-1
Ok, You're So Smart
Most likely, my convoluted solution won't work - but it'd be great if it did. Have you had a similar problem? What'd you do? What were the trade offs?
Basically, no, you can't do this the way you hope to.
You aren't an intermediate SSL authority, and you can't afford to become one. Even if you were, there's no way in hell you'd be allowed to distribute to consumers everything necessary to create new valid certificates for any domain, trusted by default in all browsers. If this were possible, the entire system would come tumbling down (not that it doesn't already have problems).
You can't generally get the public authorities to sign certificates issued to IP addresses, though there's nothing technically preventing it.
Keep in mind that if you're really distributing the private keys in anything but tamper-proof secured crypto modules, your devices aren't really secured by SSL. Anyone who has one of the devices can pull the private key (especially if it's passwordless) and do valid, signed, MITM attacks on all your devices. You discourage casual eavesdropping, but that's about it.
Your best option is probably to get and sign certificates for a valid internet subdomain, and then get the device to answer for that subdomain. If it's a network device in the outgoing path, you can probably do some routing magic to make it answer for the domain, similarly to how many walled-garden systems work. You could have something like "system432397652.example.com" for each system, and then generate a key for each box that corresponds to that subdomain. Have direct IP access redirect to the domain, and either have the box intercept the request, or do some DNS trickery on the internet so that the domain resolves to the correct internal IP for each client. Use a single-purpose host domain for that, don't share with your other business websites.
Paying more for certificates doesn't really make them any more or less legit. By the time a company has become a root CA, it's far from a fly-by-night operation. You should check and see if StartSSL is right for your needs, since they don't charge on a per-certificate basis.
I am looking into Authorize.net's new "Direct Post Method" for handling credit card transactions. Previously, my company has been using Auth.net's AIM to process credit cards without leaving our website. This method requires that we have an SSL.
However, this new DPM that Auth.net has says that the client still pays on our website but we don't need an SSL for security. This seems a bit odd to me but that's what Auth.net says. You can see the charts here: http://developer.authorize.net/api/compare/.
So, my question is this; if I have a page hosted without an ssl (http://etc...) that posts to an SSL (https:///etc...) is the POSTed information secure?
Thanks for any help.
Technically, the information may be secure in transit (after hitting the submit button). But the person filling out the form can't possibly know that it will be secure (so why should they trust your site?). After all, if the URL bar doesn't indicate that it is an HTTPS page, how are they supposed to know that it will POST to an HTTPS site?
I wrote about this once before. Although I was accused of being overly paranoid, I still maintain that I wouldn't trust a site with my credit card details if the page that I'm submitting from (and to, of course) are both SSL.
Look: The whole point of SSL is to prevent man-in-the-middle attacks (that's all it does). If your form isn't protected, then an attacker could modify the form to submit to wherever they want.
Man-in-the-middle attacks allow an attacker to modify or monitor information while in transit across the internet. With the prevalence of insecure wireless networks, BGP poisoning, attacks on DNS and new vulnerabilities being discovered every day, it's also becoming increasingly easy to perform a man-in-the-middle attack.
When faced by an untrusted certificate, every single browser I know displays a blaring error like this:
Why is that?
This strongly discourages web developers to use an awesome technology like SSL out of fears that users will find the website extremely shady. Ilegitimate (ie: phishing) sites do fine on HTTP, so that can't be a concern.
Why do they make it look like such a big deal? Isn't having SSL even if untrusted better than not having it at all?
It looks like I am being misunderstood. I am taking issue with the fact that HTTP sites cannot be more secure than an HTTPS site, even if untrusted. HTTP doesn't do encryption or identification. Phishers can make their sites on HTTP and no warnings are shown. In good faith, I am at the very least encrypting traffic. How can that be a bad thing?
They do that because a SSL certificate isn't just meant to secure the communication over the wire. It is also a means to identify the source of the content that is being secured (secured content coming from a man in the middle attack via a fake cert isn't very helpful).
Unless you have a third party validate that you are who you say you are, there's no good reason to trust that your information (which is being sent over SSL) is any more secure than if you weren't using SSL in the first place.
SSL provides for secure communication between client and server by allowing mutual authentication, the use of digital signatures for integrity, and encryption for privacy.
(apache ssl docs)
Yep, I don't see anything about third party certificate authorities that all browsers should recognize as "legit." Of course, that's just the way the world is, so if you don't want people to see a scary page, you've got to get a cert signed by someone the browsers will recognize.
or
If you're just using SSL for a small group of individuals or for in-house stuff, you can have people install your root cert in their browser as a trusted cert. This would work fairly well on a lan, where a network admin could install it across the entire network.
It may sound awkward to suggest sending your cert to people to install, but if you think about it, what do you trust more: a cert that came with your browser because that authority paid their dues, or a cert sent to you personally by your server admin / account manager / inside contact?
Just for shits and giggles I thought I'd include the text displayed by the "Help me understand" link in the screenshot in the OP...
When you connect to a secure website, the server hosting that site presents your browser with something called a "certificate" to verify its identity. This certificate contains identity information, such as the address of the website, which is verified by a third party that your computer trusts. By checking that the address in the certificate matches the address of the website, it is possible to verify that you are securely communicating with the website you intended, and not a third party (such as an attacker on your network).
For a domain mismatch (for example trying to go to a subdomain on a non-wildcard cert), this paragraph follows:
In this case, the address listed in the certificate does not match the address of the website your browser tried to go to. One possible reason for this is that your communications are being intercepted by an attacker who is presenting a certificate for a different website, which would cause a mismatch. Another possible reason is that the server is set up to return the same certificate for multiple websites, including the one you are attempting to visit, even though that certificate is not valid for all of those websites. Chromium can say for sure that you reached , but cannot verify that that is the same site as foo.admin.example.com which you intended to reach. If you proceed, Chromium will not check for any further name mismatches. In general, it is best not to proceed past this point.
If the cert isn't signed by a trusted authority, these paragraphs follow instead:
In this case, the certificate has not been verified by a third party that your computer trusts. Anyone can create a certificate claiming to be whatever website they choose, which is why it must be verified by a trusted third party. Without that verification, the identity information in the certificate is meaningless. It is therefore not possible to verify that you are communicating with admin.example.com instead of an attacker who generated his own certificate claiming to be admin.example.com. You should not proceed past this point.
If, however, you work in an organization that generates its own certificates, and you are trying to connect to an internal website of that organization using such a certificate, you may be able to solve this problem securely. You can import your organization's root certificate as a "root certificate", and then certificates issued or verified by your organization will be trusted and you will not see this error next time you try to connect to an internal website. Contact your organization's help staff for assistance in adding a new root certificate to your computer.
Those last paragraphs make a pretty good answer to this question I think. ;)
The whole point of SSL is that you can verify that the site is who it says it is. If the certificate cannot be trusted, then it's highly likely that the site is not who it says it is.
An encrypted connection is really just a side-benefit in that respect (that is, you can encrypt the connection without the use of certificates).
People assume that https connections are secure, good enough for their credit card details and important passwords. A man-in-the-middle can intercept the SSL connection to your bank or paypal and provide you with their own self-signed or different certificate instead of the bank's real certificate. It's important to warn people loudly if such an attack might be taking place.
If an attacker uses a false certificate for the bank's domain, and gets it signed by some dodgy CA that does not check things properly, he may be able to intercept SSL traffic to your bank and you will be none the wiser, just a little poorer. Without the popup warning, there's no need for a dodgy CA, and internet banking and e-commerce would be totally unsafe.
Why is that?
Because most people don't read. They don't what what https means. A big error is MANDATORY to make people read it.
This strongly discourages web developers to use an awesome technology like SSL out of fears that users will find the website extremely shady.
No it doesn't. Do you have any evidence for that? That claim is ridiculous.
This strongly encourages developers and users to know whom they are dealing with.
"fears that users will find the website extremely shady"
What does this even mean? Do you mean "fears that lack of a certificate means that users will find the website extremely shady"?
That's not a "fear": that's the goal.
The goal is that "lack of a certificate means that users will find the website extremely shady" That's the purpose.
Judging from your comments, I can see that you're confused between what you think people are saying and what they are really saying.
Why do they make it look like such a big deal? Isn't having SSL even if untrusted better than not having it at all?
But why do they have to show the error? Sure, an "untrusted" cert can't be guaranteed to be more secure than no SSL, but it can't be less secure.
If you are solely interested in an encrypted connection, yes this is true. But SSL is designed for an additional goal: identification. Thus, certificates.
I am not talking about certs that don't match the domain (yes, that is pretty bad). I am talking about certs signed by authorities not in the browser's trusted CA's (eg: self-signed)
How can you trust the certificate if it is not trusted by anyone you trust?
Edit
The need to prevent man-in-the-middle attacks arises because you are trying to establish a privileged connection.
What you need to understand is that with plain HTTP, there is absolutely no promise of security, and anyone can read the contents passed over the connection. Therefore, you don't pass any sensitive information. There is no need for a warning because you are not transferring sensitive information.
When you use HTTPS, the browser assumes you will be transferring sensitive information, otherwise you would be using plain HTTP. Therefore, it makes a big fuss when it cannot verify the server's identity.
Why is that?
Because if there's a site that's pretending to be a legit site, you really want to know about it as a user!
Look, a secure connection to the attacker is no damn good at all, and every man and his dog can make a self-signed certificate. There's no inherent trust in a self-signed cert from anyone, except for the trust roots you've got installed in your browser. The default set of trust roots is picked (carefully!) by the browser maker with the aim that only CAs who only act in a way to secure trust will be trusted by the system, and this mostly works. You can add your own trust roots too, and if you're using a private CA for testing then you should.
This strongly discourages web developers to use an awesome technology like SSL out of fears that users will find the website extremely shady. Ilegitimate (ie: phishing) sites do fine on HTTP, so that can't be a concern.
What?! You can get a legit certificate for very little. You can set up your own trust root for free (plus some work). Anyone developing and moaning about this issue is just being lazy and/or over-cheap and I've no sympathy for such attitudes.
Ideally a browser would look for information that you want kept secure (such as things that look like credit card numbers) and throw that sort of warning up if there was an attempt to send that data over an insecure or improperly-secured channel. Alas, it's hard to know from just inspection whether data is private or not; just as there's no such thing as an EVIL bit, there's also no PRIVATE bit. (Maybe a pervasive metadata system could do it… Yeah, right. Forget it.) So they just do the best they can and flag up situations where it is extremely likely that there's a problem.
Why do they make it look like such a big deal? Isn't having SSL even if untrusted better than not having it at all?
What threat model are you dealing with?
Browser makers have focused on the case where anyone can synthesize an SSL certificate (because that's indeed the case) and DNS hacks are all too common; what the combination of these means is that you can't know that the IP address you've got for a host name corresponds to the legitimate owner of that domain, and anyone can claim to own that domain. Ah, but you instead trust a CA to at least check that they're issuing the certificate to the right person and that in turn is enough (plus a few other things) to make it possible to work out whether you're talking to the legitimate owner of the domain; it provides a basis for all the rest of the trust involved in a secure conversation. Hopefully the bank will have used other unblockable communications (e.g., a letter sent by post) to tell people to check that the identity of the site is right (EV certs help a little here) but that's still a bit of a band-aid given how unsuspicious some users are.
The problems with this come from CAs who don't apply proper checks (frankly, they ought to be kicked off the gravy train for failing their duty) and users who'll tell anyone anything. You can't stop them from deliberately posting their own CC# on a public message board run by some shady characters from Smolensk[1], no matter how stupid an idea that is…
[1] Not that there's anything wrong with that city. The point would be the same if you substituted with Tallahassee, Ballarat, Lagos, Chonqing, Bogota, Salerno, Durban, Mumbai, … There are scum all over.
I'm working on a small website for a local church. The site needs to allow administrators to edit content and post new events/updates. The only "secure" information managed by the site will be the admins' login info and a church directory with phone numbers and addresses.
How at risk would I be if I were to go without SSL and just have the users login using straight HTTP? Normally I wouldn't even consider this, but it's a small church and they need to save money wherever possible.
Since only your admins will be using the secure session, just use a self-signed certificate. It's not the best user experience, but it's better to keep that information secure.
Use HTTPS with a free certificate. StartCom is free, and included in by Firefox browsers; since only your administrators will be logging in, they can easily import the CA if they want to use IE.
Don't skimp on security. Anecdotally, I have seen websites that sound similar to yours defaced just for kicks. It's something worth taking pains to avoid.
Well, if you don't use SSL, you will always be at a higher risk for someone trying to sniff your passwords. You probably just need to evaluate the risk factor of your site.
Also remember that even having SSL does not guarentee that your data is safe. It is really all in how you code it to make sure you provide the extra protection to your site.
I would suggest using a one way password encryption algorythm and validate that way.
Also, you can get SSL certificates really cheap, I have used Geotrust before and got a certification for 250.00. I am sure there are those out there that are cheaper.
In the scenario you describe regular users would be exposed to session hijacking and all their information would also be transferred "in the clear". Unless you use a trusted CA the administrators might be exposed to a Man-in-the-middle attack.
Instead of a self-signed cert you might want to consider using a certificate from CAcert and installing their root certs in the admin's browser.
Plain HTTP is vulnerable to sniffing. If you don't want to buy SSL certificates, you can use self-signed certificates and ask your clients to trust that certificate to circumvent the warning shown by the browser (as your authenticated users are just a few known admins, this approach makes perfect sense).
Realistically, it's much more likely that one of the computers used to access the website will be compromised by a keylogger than the HTTP connection will be sniffed.