4 ms·

Not saying anything really about EFF's efforts or publication, however the topic is common now ... Please don't senselessly "encrypt all the things". May I enc

Not saying anything really about EFF's efforts or publication, however the topic is common now ... Please don't senselessly "encrypt all the things". 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 http://www.sans.org/critical-security-controls ^1 though doing it effectively may be much more difficult and expensive than you imagine.

konklone 12y ago
> Logs are good, but packets and flows are better. Trust, but verify. 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.
- adricnet 12y ago
  You trust wires? 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.
halviti 12y ago
Any business can look into https traffic, and if you don't have that ability, then you either don't care about half your traffic, or you don't know what you're doing/have the proper tools. 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"
- adricnet 12y ago
  Side stepping your first point, apologies. The requirements of an individual organization are not something we can always change. 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!
rythie 12y ago
Do you have a specific example where you need unencrypted packets? What exactly are you claiming you can't see? Encrypted (SSL/TLS) connections still have packets and flows, also there are IP addresses, port numbers, sequence numbers etc. in the clear. 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-https/ https://rythie.com/blog/blog/2014/03/05/should-all-sites-use...
Someone1234 12y ago
I agree with doing threat modelling, but here's where I think we diverge: I, along with the EFF, think that HTTPS should be the "default" choice. You seem to think that HTTP should remain the "default" and that HTTPS should only be used where expressly justified. 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?
- adricnet 12y ago
  I'm not making a broad recommendation, expect maybe to slow down a bit :) 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!
snowwrestler 12y ago
You can always MITM yourself to inspect your own packet contents. 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.

konklone 12y ago

> Logs are good, but packets and flows are better. Trust, but verify. 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.

adricnet 12y ago
You trust wires? 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.

halviti 12y ago

Any business can look into https traffic, and if you don't have that ability, then you either don't care about half your traffic, or you don't know what you're doing/have the proper tools. 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"

adricnet 12y ago
Side stepping your first point, apologies. The requirements of an individual organization are not something we can always change. 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!

rythie 12y ago

Do you have a specific example where you need unencrypted packets? What exactly are you claiming you can't see? Encrypted (SSL/TLS) connections still have packets and flows, also there are IP addresses, port numbers, sequence numbers etc. in the clear. 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-https/ https://rythie.com/blog/blog/2014/03/05/should-all-sites-use...

Someone1234 12y ago

I agree with doing threat modelling, but here's where I think we diverge: I, along with the EFF, think that HTTPS should be the "default" choice. You seem to think that HTTP should remain the "default" and that HTTPS should only be used where expressly justified. 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?

adricnet 12y ago
I'm not making a broad recommendation, expect maybe to slow down a bit :) 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!

snowwrestler 12y ago

You can always MITM yourself to inspect your own packet contents. 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.