The Federal HTTPS-Only Standard: Necessary and Overdue
eff.org
eff.org
In latest Yosemite, three-finger-click definition lookups, map tiles, and even some geod location communications are still unencrypted in flight. The whole Starbucks knows what words you look up, what map locations you view, et c.
Added bonus: definition lookups happen for every Spotlight search now, too.
It is amazing that in 2015 this is not standard policy everywhere people care about security (which should be any organization that touches PII or develops software for use by more than 10 people).
Why doesn't the OS let us open "encrypted sockets"?
It's like the OS not providing TCP but only UDP. Sure, every app can include its own TCP stack. But I'd rather the OS do it.
With IPSec you can tell the OS "open an encrypted connection to 69.231.14.52" and the OS will verify that you're actually talking to 69.231.14.52 and no-one else can read your messages. But that's not actually terribly helpful, because what you want to ensure is that only Bob can read your messages. And only the application knows who Bob is.
Now: Application: Hey OS, what is example.com's IP? Okay, now give me an unencrypted connection to example.com's port 80.
Desired: Hey OS, give me an encrypted connection to example.com's port 443. (+ optional encryption params like minimum key strength)
Why can't encryption be an OS level task, exactly?
Along similar lines, I think it's strange that I now see warnings in Chrome for SHA-1 certificates but no warnings at all for http.
So in short hostname-based authentication is mostly useful for web browsers - which is why it's in the web browser, not the OS.
(Also, pragmatically, existing OS-based key management is terrible - just try and use the Windows dialogues to set up an SSL client certificate. For many users the very idea that you manage your keys separately from the programs you use them in is confusing. So browsers would rather provide their own cross-platform UI for key management, even if the OS offers a "managed SSL keystore" as most OSes do)
As to the UI: Yes, but that's precisely because it is currently unclear who is responsible. Java has its own keystore, FF has its own but Chrome doesn't, even some libraries have their own or they don't, depending on the OS. It's a mess. A mess that I don't care about, as a user.
I want a central key store that apps tap in to. When I revoke a cert for Diginotar, I don't want to have to grep every file in my entire filesystem for that string on the off chance some crazy statically linked lib installed a local cert store somewhere.
And sure, an app wants to create a special case just for itself (e.g. a client certificate only for mail), let it. But I'd like that to be the exception, not the rule.
Cert management is a mess right now, and both developers and users are duped.
You're exactly right on this – APIs need to be secure by default. Yes, I'm sure that that'd make some of the certificate management issues more pronounced but that's something we need to solve anyway; increasing the expectation that everything should be encrypted will only help.
It bugs me that it costs more for a wildcard domain cert than it does to host with a VPS for a year. I'm not saying it's prohibitively expensive for hobbies using multiple certs, just the same it shouldn't be this way.
Encrypting at the host level would be actively unhelpful (e.g. it would make failover or forwarding harder) and wouldn't gain you much in the way of security. You just want to encrypt the message to the actual recipient.
> chat
Again hostname-based auth is actively unhelpful in a federated system like IRC or XMPP (you want to failover to a different host if a particular host is down), and offers minimal security in a centralized-server system.
> VPN
I think a VPN is inherently the wrong approach to security; it's trying to create a network you can trust, but networks are too big to secure.
> VNC
How often do you VNC to a box with a stable hostname? I only ever use it to connect between my (coffee shop or wherever) laptop, my (dynamic IP) home machine and my (dynamic IP) dev machine at work.
You wouldn't want to deal with certificates and keychains and all the UI stuff that comes with it from within an application.
Why not?
So you are saying these are our only 2 options?
1. I don't know who you are so we can't encrypt our conversation.
2. I know who you are so we can encrypt our conversation.
Why is there not a third option?
3. I don't know who you are but we can still encrypt our conversation.
And by "someone," that doesn't necessarily mean an actual person specifically targeting you, it may just be an infected machine or router that snoops on everyone.
But if you're trying to reach some other site, how would you know if someone is pretending to be the site you're trying to reach? Encryption is not much use in protecting privacy, if your encrypted connection goes to an imposter. That's why authentication matters as much as encryption for surfing the web.
It seems to me that implicit in the argument against option 3 is the assumption that if we have a system in which encryption is not tied to authentication that the net will be filled with MITM attackers, thus effectively rendering option 3 identical to option 1.
Is that a valid assumption?
http://arstechnica.com/tech-policy/2013/04/how-a-banner-ad-f...
http://gizmodo.com/gogo-is-using-man-in-the-middle-malware-t...
Keep in mind these are legitimate, professional ISPs doing this, so we're not even into criminal or state-level MITM attempts, let alone basic griefing tools like Firesheep.
So yes, it is a valid assumption that the net is filled with MITM attackers.
What are you missing?
You can set your queries to stay local if you disable "spotlight suggestions" and "bing web searches" in the spotlight settings. Definitions, based on the what the info on the settings page says, should be just local.
Hopefully this helps someone else, I've just disabled them.
This should never have been a conversation about performance and it was the technical folks making it one of performance. The only issue raised should have been about proper certificate management.
Fortunately at the university we pushed through https on the product despite the pushback, but it never would have even been a struggle in the first-place if not for the focus on the wrong metric.
On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10 KB of memory per connection and less than 2% of network overhead. Many people believe that SSL/TLS takes a lot of CPU time and we hope the preceding numbers (public for the first time) will help to dispel that.
You can run OpenSSL today on an embedded processor which might appear to be as slow as a 90s server processor but it's still likely to have things like AES support in the CPU, an optimized bignum library, tuned assembly implementations for the most common algorithms and at least the very least the compilers in use now generate much better code. I'd be surprised if you wouldn't see a significant benefit taking some 90s crypto code and compiling it with a current version of clang/gcc.
I found a couple sources claiming that a Pentium 3 should be capable of 200 handshakes per second max (1024 bit RSA), and also that it could hash over 50Mbps with 3DES or well over 100 with RC4-MD5.
I can't find if those Google servers had AES acceleration, but the chips with it had only just come out.
So looking at the year 2000: Pentium 3 is about 10x slower at handshaking, and somewhere around 10x[1] slower at encrypting depending on algorithm. So if you can spare 10-20% CPU, I don't see any major problems with going full-SSL.
[1] This one can vary more depending on exactly what you compare. Could be close to equal speed if you accept a worse algorithm for 2000, and don't have brand new AES-NI chips in 2010. Could be a huge multiplier between 3DES and AES-NI, but your server doesn't need a gigabyte per second of SSL traffic.
you also really need to use spdy and have a plan to move to http 2
Just leave your existing HTTP property exactly as it is. Add a load balancer in front. Have the load balancer receive HTTPS and then send the traffic through to the property as HTTP, and finally restrict all other external access to the HTTP sites (i.e. load balancer only).
You can buy off-the-shelf appliances which will do this for you. Except for maybe a firewall change, no changes would have to be made to existing code or servers.
We did our first site HTTPS-only the exact way you describe, but didn't anticipate half our embedded content disappearing. The situation is getting better fast, but even a year ago a number of pretty well-known services like Scribd and Storify didn't fully work over HTTPS.
Video is the worst; every TV network has its own embeddable video player, and most of them did not work at all over HTTPS until very recently. Again, that's getting better pretty fast.
https://w3c.github.io/webappsec/specs/upgrade/
It is included in the Chrome 43 beta [1], and Firefox is working on it as well [2]. This is excellent news for folks looking to upgrade existing sites to HTTPS.
[1] http://blog.chromium.org/2015/04/chrome-43-beta-web-midi-and...
Maintenance costs shouldn't change, unless you're contract only (and SSL only adds one additional bottleneck per year or two over running the base web servers).
I'd be curious to hear how yoru costs would change, as well as where the $10k per month figure comes from.
The benefits of encrypting (or at least offering encryption) to your customers would be very fairly significant.
May I encourage some requirements gathering and threat modelling? Who are you trying to keep out (in?) of your application communications? Why?
The unfortunate requirement of common business systems is that we need visibility into what these systems are doing for troubleshooting, audit, and incident detection. Logs are good, but packets and flows are better. Trust, but verify.
Driving to encrypt all traffic, all the time may be a noble goal^1, but please understand that there are good people who need to adapt requirements to their organizations and projects. This is one of the points, along with firewall policies, user privileges, useful remote logging, and ... well, have a look at the CC20[1] for more.
http://www.sans.org/critical-security-controls
^1 though doing it effectively may be much more difficult and expensive than you imagine.
shrug You're not wrong, but it's more important to have wires that can be trusted than to have wires that can be perfectly audited.
To me this sounds like the debate over WEP. I think it is still not commonly understood how secure wires are. I think that the WEP protocol and successors do a good job of fulfilling the desire for "wired equivalent privacy", but many people expect something very different from encrypting wireless networks ... and I find the arguments for HTTPS everywhere to have similar gaps.
And who said anything about perfect? :D I'm just trying to do what I can to cut away at the Fog of War, plus maybe save IT and NetEng a great deal of work.
Allowing anyone on your network (or your destination's network) to inject whatever they want into your datastream is not an acceptable tradeoff for "I want my job to be easier"
There are other technologies to detect and resist injection in communications beside encrypting the whole network, aren't there? Maybe you just need nice HMACs and good crypto of that for that feature. Would that make more sense in your applications? would you trust that more than relying on the OS, or the routers to protect your application / verify the communication source?
Thanks for responding and fiercely debating, cheers!
If it's traffic to your own servers, then you can plug the certificates into the monitoring tools.
I wrote about why all sites should use HTTPS: https://rythie.com/blog/blog/2014/03/05/should-all-sites-use...
If there are legitimate technical reasons to use HTTP then use HTTP. However HTTPS should be on most sites or services unless you have a specific technical, legal, or otherwise reason not to do so.
Keep in mind that every HTTP site you visit at Starbucks can be MITM-ed. So if you're visiting a HTTP site and then hitting a "login" or "contact" button which redirects you to HTTPS one then for all intents and purposes the entire site is now not MITM protected since an attacker can change that link to point to an insecure domain they control. HSTS won't even protect you from this if you're using sub-domains (since the attacker controls the link itself, so can link to another site they control).
Another popular example is: What if someone sitting in Starbucks is looking up AIDs information or something else potentially damaging to their reputation? If all of the federal government's web-sites are HTTPS by default then that little AIDs informational site is likely HTTPS also, however if HTTPS has to be justified using some kind of threat model, then more than likely it won't be HTTPS as it doesn't contain the kind of content people typically protect (just static HTML pages and images).
So in the threat model are you going to examine the possibility of reputation damage and complex phishing scams (e.g. replacing a government department's phone number)? And if you do look at it at that level are any sites really going to be able to justify not being HTTPS?
It sounds like you have lots of usecases for applications that need protection against injection , MITM, or eavesdropping. It's great that you understand that. Those sites and apps need that protection, and the network protocols are one place to look for it.
Also, there is a huge difference between "all web software should support encryption" and "turn all of that on by default". I just want a broader discussion of the costs and more discussion about the problems people are trying to solve.
Thanks!
If you're on your own computer, connecting to a 3rd party, you can run a local proxy that decrypts packets between you and the 3rd party.
If you're running a web server, you can install your cert on the load balancer, firewall, IDS, etc.
If you're running a corporate network, you can create a local CA and decrypt traffic in and out of your network.
There are a variety of tools and services to make it relatively easy to do these things.
The question is, do you want strangers to see your stuff? That's what HTTPS everywhere is about. If you don't care if other people see your stuff, then fine, but be aware that when you're running a server you're tacitly making that decision for all your users. They might not all feel the same way you do.
If you passed ssllabs last year, give it a go this year and you may be shocked to see all the new known problems.
https://www.ssllabs.com/ssltest/
HTTPS-ONLY is useless if it is not done right.
and MITM is still too easy
Adam Langley said something about enforcing secure TLD restrictions in Chrome a while ago, not sure if that ever got done.