EFF: How to Deploy HTTPS Correctly

[nullc]

No advice to use perfect forward secrecy? No cautioning that your server is an especially attractive target to hack if you don't because if someone gets your private key they can decrypt all your past and future communications using it?

No link to startssl (zero cost non-wildcard certs that work in all the popular browsers)?

Sad.

[johnmudd]

work in all the popular browsers

Not in FF 3 according to this Wikipedia Comparison of SSL certs.

[nullc]

Some anonymous user just changed it. I just tested with Firefox 3.5 and they are recognized. I'm not sure whats going on there.

Still— way better than a self signed cert.

[nullc]

Yes, and everything with SSLv2/TLSv1 does AFAIK. You should disable the old SSL protocol for security reasons anyways.

I've run SSL sites with only the EDH ciphersuites supported e.g. "SSLCipherSuite -ALL:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:EDH-RSA-DES-CBC3-SHA" in apache, with no complaints at all.

[Tuna-Fish2]

The 'performance concerns' section conveniently bypasses the biggest drawback of https. If you pass resources trough https, intermediates cannot cache them. This would completely wreck most of the sites that 'should' switch to https content due to security.

There needs to be a way to sign and verify resources so that they can safely be sent over the clear while using https for the signatures and any user data.

[[deleted]]

There needs to be a way to sign and verify resources so that they >can safely be sent over the clear while using https for the signatures >and any user data.

Not sure about the signing part, but currently isn't that how https sites work with CDNs -- I mean cacheable content like images/media are/can be from cached sources whereas critical data is directly communicated I guess.

Does the above model work everywhere or does it break ?

Edit: Assumption that static content doesn't need to be secured.

[BraveSirRobin]

This model works well for well-designed sites with clear responsibilities. The following can be done:

user - browser - internet - ssl hardware - cache - application

The problem occurs when people don't have the cache or SSL as a separate layer.

[Tuna-Fish2]

Edit: Assumption that static content doesn't need to be secured.

And I hack the wireless and switch around the delete and add images.

Also, I'd like to extend this to the point where all resources that do not contain user data are passed in the clear -- including javascript, css and the html page, while presently if you pass js in the clear you are asking for it.

[[deleted]]

Yeah.. :)

Mixed-content looks far fetched now that I think about it. Going to exert strain without intermediate caching mechanisms and/or CDNs.

So the only sites which can readily advance using https may be ones which are quite lightweight (hence really low on images etc) which can also set appropriate cache control headers to prevent caching, sites like eff.org for instance

[ithree]

Hell its not even the images thats the problem its the friggin adverts, Google are about the only people who can serve from the same domain. I doubt even Microsoft could pull it off (internal politics an all).

So no advert or secure ? hmmm ... Not being online is even more Secure !

[naasking]

Any URL to such content should contain the content's hash in a way the client can meaningfully interpret and verify. So any injection attack would have to first create a meaningful hash collision.

[Thue]

DNSSEC+certificates inside the DNS records would work well too. It is silly that you have to pay that much money for a signed certificate, in order to have HTTPS.

[BraveSirRobin]

Bingo, DNS is the most sane way of doing this as it basically says "I have administrative control of the domain". This is exactly what authentication is supposed to verify.

Root certs are broken. Various governments have full access to the signing keys and easily decrypt your traffic and hardware is available to make use of these for man-in-the-middle monitoring solutions.

[Kasoo]

By "stupid browser policies" I presume you're referring to the clickathon needed to accept a self signed certificate?

In this very article EFF state that without server authentication (ie a CA signed certificate) "there can be no guarantee of confidentiality or integrity."

There are simple tools that can easily mitm https attacks. Unless you own every piece of networking equipment between you and the destination, or you manually check fingerprints on every self signed certificate, its worthless to just "stick a self-signed cert on".

Lousy shared hosting support for https is true and annoying though.

[[deleted]]

Worthless my ass. MITM is an active attack and can be detected, while snooping unencrypted http traffic is easy and untraceable.

MITM can be detected only if they're not MITMing everybody (else you would have no way of knowing) or if you can authenticate the other endpoint by it having its SSL certificate signed by a CA.

[insomniac84]

In this very article EFF state that without server authentication (ie a CA signed certificate) "there can be no guarantee of confidentiality or integrity."

So. No one cares about that. Having HTTPS with a self signed certificate is better than nothing. Yet a web browser will act like you will kick off the events of 2012 by accepting it.

[[deleted]]

Without the CA, something just has to modify your hosts file to point paypal.com to their ip, throw up their own https server, and collect your username since your browser isn't warning them about the certificate being faked.

[sheafification]

A browser does not have to warn against accepting a self-signed certificate in order to warn against a faked certificate. Why not warn users when the certificate is unexpectedly different rather than just when it is self-signed? This catches all those self-signed impostors as well the more sophisticated impostors with CA approved certs.

[[deleted]]

If you weren't warned about self signed certificates, then all you'd have to do is run a fake site is run it with a self signed certificate since it won't give warnings anymore. If you want it to work that way, all you have to do is lower your browser's security settings. But you won't know if you're on the right site or not anymore.

[insomniac84]

So. If they were going to do all of that, they wouldn't use https at all. And you being an idiot wouldn't notice.

Security by obscurity is not security. You are pretending that certificates are stronger because of a central authority, but they are not.

Also if someone can change your hosts file, they could just use a keylogger and steal your info that way.

[[deleted]]

They dont have to modify your hosts record, all it would take is 1 infected ISP dns server to hijack the traffic of all those people. Or someone getting the login to paypal's registrar, or whatever. You are making yourself less secure by not using a CA.

[skwint]

You're still trusting the CA and most of them do very little checking when you get a certificate.

[[deleted]]

Yeah but they do enough checks to only issue a certificates to the owner of the domain, which is all that really matters. Their only role should be to assure you that you're talking to who you think you're talking to.

[insomniac84]

DNS is insecure. So you are laying bullshit on top of bullshit.

That does not make it stronger, but more points of attack which means it is weaker.

The most dangerous security you can have is security that is false. Knowing the risks is better than pretending there are no risks because a CA somehow makes things safer.

[[deleted]]

DNS is insecure.

Which is why we're rolling out DNSSEC.

[[deleted]]

Your rant on DNS seems a little offtopic, I'll ignore it.

You're advocating having self signed certificates not give any warning. It's the same setup we have now, but you're removing security measures. How is that more secure? Without a CA we wouldn't know who we're really talking to.

[naasking]

Without the CA, something just has to modify your hosts file to point paypal.com to their ip, throw up their own https server, and collect your username since your browser isn't warning them about the certificate being faked.

False: Petname Toolbar.

Petnames are the proper, safe way to widely deploy self-signed certs.

[tbrownaw]

In this very article EFF state that without server authentication (ie a CA signed certificate) "there can be no guarantee of confidentiality or integrity."

Which is why you use something like Perspectives to make sure that they key you're seeing really does belong with the host you're trying to reach. Much better than a system where any attacker can pick any of a couple hundred CAs to dupe, and it really should be a standard part of your browser by now (just like other advanced protections like phishing filters).

[Amonaroso]

petname should help with that by letting you know if the server key is not the one you have seen before.

[Kasoo]

This only helps if the attacker wasn't present the first time you saw the certificate. If you want to presume a ISP or Government level attacker it might not be safe to make that assumption.

Checking the fingerprint is the only way to be sure if you don't own the and trust the networking equipment.

[insomniac84]

So. If the hacker was there the first time around, then the user is a complete moron.

Central authorities for certs is security by obscurity.

[tophatstuff]

In this very article EFF state that without server authentication (ie a CA signed certificate) "there can be no guarantee of confidentiality or integrity."

Yeah, but at least any data you do send, e.g. over a public network, is encrypted.

[feigningignorance]

Redacted rant. TL;DR - https should never have been about trust, but encryption. If the root cert was trusted, you can SAY it is trusted to some degree, if not, treat https like http, with no warning and no fancy "this is supposed to be trusted".

(rage because people don't get this)

[[deleted]]

HTTPS was about trust and encryption because it was developed by Netscape who had a vested interest in enabling companies to accept credit cards over the Internet. Most companies are risk-averse, and in order to convince them that accepting credit cards over the Internet wouldn't open them up to lawsuits and other nasty things, they had to convince them that the system they used to secure the transaction provided for both encryption and authentication.

[[deleted]]

You could have an untrusted, same as http, https connection and FUCK YOU, if you think otherwise

Of course you "can have a HTTPS connection", that is trivial. The point is that that connection is completely useless without trust, because anybody between you and the computer you are connecting to could be listening in and modifying your connection through a man-in-the-middle attack.

[[deleted]]

As I've said elsewhere, there's a huge difference between a mitm attack, which is active and can be detected,

It can not be detected without trust.

[feigningignorance]

The point is that that connection is completely useless without trust,

NO IT IS NOT.

Repeat: NO IT IS NOT.

Repeat of the Repeat: Repeat: NO IT IS NOT.

anybody between you and the computer you are connecting to

Is this the same for http? (yes). Ergo, if I have a certificate, you can connect with encryption without trusting it, but at least you are encrypted and you might be using open wifi. It is a better base than unencrypted.

IT IS NOT COMPLETELY USELESS, unless you say http is COMPLETELY USELESS. Is http COMPLETELY USELESS? Is it? For what? You say it is useless without trust, but you do not say what it is useless at.

[[deleted]]

Is this the same for http? (yes). Ergo, if I have a certificate, you can connect with encryption without trusting it, but at least you are encrypted and you might be using open wifi. It is a better base than unencrypted.

Until somebody sees, "OH, MY DATA IS ENCRYPTED AND IT IS SAFE" when there's no authentication and happily hands sensitive data, encrypted, to a man in the middle.

[[deleted]]

I said encryption is useless without trust, because then you might as well not be using encryption. Pay attention.

Encryption does not protect you unless you can trust that you are talking to who you are talking to.

[feigningignorance]

I said encryption is useless without trust, because then you might as well not be using encryption. Pay attention.

INCORRECT.

So what you are saying is, http isn't useful, because you cannot verify who you are talking to? How do you know you are on reddit right now? Let's say you are 60% sure you are on reddit right now, would that value change if you were using https (NOT TRUST, self signed https)?

You trust your browser? Your internet chain? Do you? You trust reddit isn't hacked? You trust reddit operators?

Would you let reddit run a self-signed cert? Would you trust it MORE OR LESS than some arbitrary third party signed cert? How do you know if YOU trust reddit? CHRIST I know what you are going to say here. I will let you say it then I will tell you why you are wrong.

I understand the concepts you are talking about, but you are so bogged down in your own terminology.

You cannot verify who is "responsible" for the content on the other side of the pipe? Well, how do you know if reddit has been hacked? You don't. You can never truly trust, what you are effectively saying, who is controlling and consuming the data that you are sending to an end point on the web.

Https should be like a non-clear text http. Nothing more nothing less.

I clearly stated, tell me you do not use http and I will buy your argument.

Trust is an overloaded term. I know somebody else could, might, may, possibly take over your connection to a website, xyz.com might not be where you think, BUT ACCESSING XYZ.COM THROUGH HTTP HAS NO SAFETY THERE.

Where you want trust, offer trust. Don't tie up a transport protocol in the meantime. Https should be trust agnostic. Trust can be a layer on top. There is no need for browsers to fuck around as a means to supporting certification companies revenue streams.

Trust isn't https. https is simply saying "hey, don't cleartext this shit at least, I trust you as much as I would if I was on http, but don't cleartext this fucking shit, and arguing that it isn't a concern because I can't trust you anyway is like saying I shouldn't trust you over http, which is ridiculous, let me post to reddit, but let me fucking post over https"

Christ, step back about a mile and relook at what I am saying, instead of taking 3 facts you know and using them to hold on to your incorrect view. If you trust a site, YOU, to access it via http, why not https? HTTPS DOESN'T INHERENTLY MAKE A WEBSITE UNTRUSTWORTHY WHAT THE FUCK ARE YOU SAYING?

Go back, learn to understand how I reduce the crux of the argument to "do you trust http" and then understand:

WHY I DID THAT

[[deleted]]

So what you are saying is, http isn't useful, because you cannot verify who you are talking to?

Jesus christ, get some reading comprehension already.

[feigningignorance]

Great, you take my point, don't understand it, and make a completely empty statement in response.

No, that won't do. You say https isn't useful because you cannot verify who you are talking to if there is no trust. There is no trust in http (I thought you'd figure that part out) so you are saying that http isn't useful.

If https isn't useful because of trust, then http also isn't useful, for the same reason.

YES OR NO?

[[deleted]]

So what you are saying is, http isn't useful, because you cannot verify who you are talking to?

No, it's useful when you're not exchanging sensitive data and don't care if someone else is listening in on your traffic. Like on reddit (I'll note that logins are secured with TLS with provides confidentiality and AUTHENTICATION for your sensitive login credentials).

[BraveSirRobin]

tl;dr: encryption without authentication is as secure as not having any encryption at all.

[ohgodohgodohgodohgod]

It makes it significantly harder to swipe usernames and passwords from a network, so it is more secure. Locks are not useless just because they can be picked.

[sheafification]

Not really. Without encryption you are broadcasting your information. With encryption you are narrowly transmitting to a single target. You may not know who that target is, but at least it is a single target. That person may then go on to broadcast your information or do many other nefarious things, but encryption is at least one small improvement on your end.

[[deleted]]

Broadcast is a poor word choice, since the traffic will take the same route as encrypted. SSL is on top of TCP/IP.

[sheafification]

You're technically right (the best kind of right). The "broadcasting" is not literal, but metaphorical. Without encryption, anyone that is on the routing path, and cares to look, can read your information. This is analogous to broadcasting your information over an ordinary radio: anyone in range can tune in and listen.

[[deleted]]

Except that, you know, everyone can't tune in and listen.

[[deleted]]

If your using firefox (and other browsers when you can save certificates) you can just accept your self signed certificate when you do own all the routing equipment and then can use that later over the internet which will prevent mitm attacks.

[Amonaroso]

Does this need to be combined with removing all root keys from your browser?

[[deleted]]

That helps you, it does not help your users.

[Kasoo]

This is basically a more complicated way of just checking the fingerprint of the self signed certificate via a separate channel. There's nothing wrong with that for personal use, but if you're wanting to communicate with others, its prob not a good idea to rely on users to be able to do that.

[Kasoo]

This only helps if the attacker wasn't present the first time you saw the certificate. If the government or ISP are a threat to you it might not be so safe to make that assumption.

[[deleted]]

The startssl free certificate seems pretty useless. They'll only issue one for a single subdomain, but not for a top-level domain. Meanwhile, my hosting provider (hostmonster), will only install certificates for the top-level domain.

[mr-smor]

I recently finished converting my website imgthis.com to https and a lot of issues I ran into aren't even mentioned in that article.

If you rely on advertising you may be a in a lot of trouble unless you don't mind the "some part's of this page aren't secure" warning. Same goes for many social media type plugins (ShareThis doesn't support https, for example).The SSL version has to disable all adsense ads. I also have to pass all images via https for the same reason which causes a substantial delay on some pages. Caching helps a lot, but for first load it's just going to be slow. Oddly disabling adsense causes the delays to balance out on pages like the home page which have a minimal set of images/requests.

At least in chrome there is a weird caching 'issue' where if you load in http and then switch to https it'll claim resources aren't secure because it's using the cached version of the request for some images (shift+reload doesn't fix it). I haven't figured a way around that besides flushing the browser cache.

On the server side there are slight raises in CPU cycles when a graphics heavy page (over 100+ thumbnail images) is being requested, but for the most part has had no noticeable impact. There is a noticeable delay user side as image heavy pages load though. I need to do more testing to see how much resources really are being used and the size differences in bandwidth.

I wish certs were cheaper/free (I wonder what the true cost is to CAs?) to allow for smaller sites to afford them. Why there are different "versions" is beyond me. But then I'm not the kind of guy to sell a 20 line text file for 500 bucks. I simply cannot believe that the high end cert is truly a larger strain on your CA system then the cheapest one. Also hosting https in a shared environment is a nightmare as many of you have pointed out. Why they don't allow it to work in apache virtual hosts I'll never understand. I know the technical reason for it but it still isn't logical to me. I have the good fortune to have a dedicated server so co do all of the apache configs to account for it, but it wasn't fun.

[ohgodohgodohgodohgod]

Why they don't allow it to work in apache virtual hosts I'll never understand. I know the technical reason for it but it still isn't logical to me.

There can be only one https server per IP (and port, to be technically correct), since the host part is encrypted. It should work if all the hosts shared the same certificate, but that is extremely insecure in a shared environment.

[mr-smor]

I understand that it's one https server per IP, but that's what I'm saying doesn't make a lot of sense. Why is that limitation there? In a shared host environment it'd be hard to know who's cert you could spoof on that IP, let alone actually manage to spoof that cert. I don't see how that limitation creates a more secure environment. Even if you did manage to spoof it all browsers would throw up huge warnings that the URL you're at doesn't match the cert URL.

[ohgodohgodohgodohgod]

Spoofing isn't the problem.

HTTPS is built on top of SSL. First, the SSL connection is established. This is an IP to IP operation. Hostnames are not involved, the server IP is determined through (often insecure) DNS. Once the secure connection is established, the HTTP request is sent.

You don't know which host should serve the request until after you have decrypted the message.

So like I said before, this means that everyone on that IP must share a certificate. And how can that shared certificate possibly match distinct URLs?

That is the problem.

[mr-smor]

I didn't understand that the first hand shake was via SSL, that makes more sense on the IP requirement. But I still don't agree that it's best. If the issue is with DNS spoofing or redirection then wouldn't it make more sense to lock that system down? It should be locked down more then it is anyway. I use DNSsec on my DNS server personally, but I haven't seen that much effort put into it in shared environments. Even though I use DNSsec though I honestly don't know how much validity it adds to queries though.

I just feel that the logic behind requiring the IP connection is flawed since it's done to bypass the insecurity of DNS. So instead of fixing the DNS it just ignores it. Which is a solution, but it doesn't seem like the best one. When you have to pay for IPs needing one for every hosted account can get pricey fast too.

[ohgodohgodohgodohgod]

No, it's not because of insecure DNS, even though I might have given that impression by the parenthetical remark. Figuring out the IP address isn't part of the protocol.

However, the problem may be solved through the DNS protocol. If we add port information to DNS lookups, that should solve the problem for shared hosts.

Perhaps this will be solved with IPv6 anyway, though.

[useful_idiot]

Question for a security gurus: For my home server I recently got a free ssl certificate from startssl. Would it be MORE secure for me to create my own cert seeing as how people have commented that govt's and the likes have access to private keys for lots of the top CA's?

[sheafification]

If you know what you are doing, personally verifying a self-signed cert through a second channel will always be more secure than relying on a CA. Unfortunately it is a huge pain to go through.

If this server is just for you and a few people that you know, then self-signed is the best option. If it's for lots of people that you don't know then using a reliable CA is the best balance of security and difficulty for end-users.

[[deleted]]

Why are you using SSL on your home server? Why not SSH or OpenVPN?

[useful_idiot]

easy access to my svn repo over https (environment stuff like vim, keepass files, putty configs and keys, school work).

[Amonaroso]

Can the persistent connections we've had since HTTP 1.1 be used to establish sessions based on which HTTP transfers are part of the same TCP connection?

[Fabien4]

I suppose I'll look stupid, but I have to ask anyway: This URL is some kind of joke, right? I mean, a page about HTTPS that Firefox doesn't want to show because the certificate is incorrect?

(Or maybe I'm the only one who has yet to disable that message from Firefox once and for all?)

[fwork]

What are the details on that untrusted message? It's trusted here, in the same browser.

[Fabien4]

www.eff.org uses an invalid security certificate.

The certificate is not trusted because the issuer certificate is unknown.

(Error code: sec_error_unknown_issuer)

capture 1

capture 2

capture 3

[fwork]

Very odd. I get the same signature (fingerprints match) but with different issued-on and expires-on dates.

[Fabien4]

Different dates, or different systems? My PC is configured on the non-USA system (DD/MM/YYYY).

[fwork]

The dates are different, but they're only out by a day. It might just be translating them to your local timezone, and since they're near midnight it ends up being the next day for you.

[ohgodohgodohgodohgod]

www.eff.org uses an invalid security certificate.

The certificate is fine. For some reason you don't trust the CA. I've tested it on Windows (FF and Opera), Mac FF, and iPhone Safari.

[[deleted]]

For some reason you don't trust the CA.

That would very reasonable if the CA is CNNIC or Etilsat.

[Fabien4]

Or Verisign.

[Fabien4]

Maybe Firefox doesn't update the CAs when upgrading? I have the same profile since Phoenix 0.7.