2016 Saw A Massive Increase In Encrypted Web Traffic (eff.org)
EFF's "Deeplinks" blog has published nearly two dozen "2016 in Review" posts over the last nine days, one of which applauds 2016 as "a great year for adoption of HTTPS encryption for secure connections to websites." An anonymous reader writes:
In 2016 most pages viewed on the web were encrypted. And over 21 million web sites obtained security certificates -- often for the first time -- through Let's Encrypt. But "a sizeable part of the growth in HTTPS came from very large hosting providers that decided to make HTTPS a default for sites that they host, including OVH, Wordpress.com, Shopify, Tumblr, Squarespace, and many others," EFF writes. Other factors included the support of Transport Layer Security (TLS) 1.3 by Firefox, Chrome, and Opera.
Other "2016 in Review" posts from EFF include Protecting Net Neutrality and the Open Internet and DRM vs. Civil Liberties. Click through for a complete list of all EFF "2016 in Review" posts.
Chipping Away at National Security Letters: 2016 in Review
Everybody Wants To Rule The World (Wide Web): 2016 in Review
Fighting for Fair Use and Safer Harbors: 2016 in Review
Secure Messaging Takes Some Steps Forward, Some Steps Back: 2016 In Review
Most Young Gig Economy Companies Way Behind On Protecting User Data: 2016 In Review
Dark Skies for International Copyright: 2016 in Review
Congress Gives FOIA a Modest but Important Update For Its 50th Birthday: 2016 in Review
Our Fight to Rein In the CFAA: 2016 in Review
The Patent Troll Abides: 2016 in Review
DRM vs. Civil Liberties: 2016 in Review
The Fight to Rein in NSA Surveillance: 2016 in Review
The Year in Government Hacking: 2016 in Review
What Happened to Unlocking the Box? 2016 in Review
Top 5 Threats to Transparency: 2016 in Review
Technical Developments in Cryptography: 2016 in Review
This Year in U.S. Copyright Policy: 2016 in Review
Open Access Rewards Passionate Curiosity: 2016 in Review
Censorship on Social Media: 2016 in Review
Defending Student Data from Classrooms to the Cloud: 2016 in Review
Protecting Net Neutrality and the Open Internet: 2016 in Review
U.S. Trade Representative Gets Piracy Website Listing Notoriously Wrong
HTTPS Deployment Growing by Leaps and Bounds: 2016 in Review
Defending the Digital Future: 2016 in Review
Other "2016 in Review" posts from EFF include Protecting Net Neutrality and the Open Internet and DRM vs. Civil Liberties. Click through for a complete list of all EFF "2016 in Review" posts.
Chipping Away at National Security Letters: 2016 in Review
Everybody Wants To Rule The World (Wide Web): 2016 in Review
Fighting for Fair Use and Safer Harbors: 2016 in Review
Secure Messaging Takes Some Steps Forward, Some Steps Back: 2016 In Review
Most Young Gig Economy Companies Way Behind On Protecting User Data: 2016 In Review
Dark Skies for International Copyright: 2016 in Review
Congress Gives FOIA a Modest but Important Update For Its 50th Birthday: 2016 in Review
Our Fight to Rein In the CFAA: 2016 in Review
The Patent Troll Abides: 2016 in Review
DRM vs. Civil Liberties: 2016 in Review
The Fight to Rein in NSA Surveillance: 2016 in Review
The Year in Government Hacking: 2016 in Review
What Happened to Unlocking the Box? 2016 in Review
Top 5 Threats to Transparency: 2016 in Review
Technical Developments in Cryptography: 2016 in Review
This Year in U.S. Copyright Policy: 2016 in Review
Open Access Rewards Passionate Curiosity: 2016 in Review
Censorship on Social Media: 2016 in Review
Defending Student Data from Classrooms to the Cloud: 2016 in Review
Protecting Net Neutrality and the Open Internet: 2016 in Review
U.S. Trade Representative Gets Piracy Website Listing Notoriously Wrong
HTTPS Deployment Growing by Leaps and Bounds: 2016 in Review
Defending the Digital Future: 2016 in Review
A true hero to anyone concerned about internet privacy.
It would have been all great if governments couldn't exert power over certificate authorities. The reality however is different.
We need a universally adopted system which doesn't allow to circumvent the process of issuing certificates or at least protect against rogue certificates - then we may sing praises.
+ Enigmail + Full disk encryption + Tor + Tails + Burner laptop @ coffee shop + Groucho Glasses and trenchcoat + getaway car + fake passport.
As much as I hate and disdain the spying empire Google; private companies only thought about adopting https because of Google's hint of ranking sites based on utilising https encryption.
Anything Google does is for its own selfish purpose, not for the good of humanity - so the reason for the push towards https is so that Google (almost alone) has analytics and information about site visitors and the amount of money e-commerce and such sites are making. Without encryption, countless other firms (such as alexa) was capturing user analytics through approaching different providers, and often directly from ISP's.
Remember, Google's trackers are almost ubiquitous (unlike facebook), so they want to own alone the vast amounts of info on users and organisations - and then use this info to either catalogue people and/or sell this to evil companies/organisations, such as insurance firms and governments.
Information is power, user information is even more power, especially if you alone hold that data.
The goal is to stop mass surveillance. If GCHQ or the NSA really want that data, they will hack the site anyway.
By using HTTPS everywhere it just makes their job harder, so they can't spy on everyone by default.
const int one = 65536; (Silvermoon, Texture.cs)
SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
And on topic: I don't know much about cybersecurity but I would like to make sure the emails I send can not be read easily by people to whom my emails are not addressed. How can I go about that?
All you have is an address. To make an analogy to physical mail there's some security in sending letters instead of postcards but really most is in the postal system and the security of the recipient's mailbox which is out of your control. Not much you can do if I want it on my web mail, it's going to semi-permanently live on someone else's server in plaintext. If you want more security than that you need your communication partner to work with you, even if it's so low tech that you call them up and say the password for the encrypted attachment is luggage12345. If they don't want to play ball, no game.
If your security concerns resonate well with the recipient and all you want is security and not anonymity in a convenient package I'd suggest you both forget email and install Signal. It's mainstream, open source, you need a phone (cell phone, Google Voice, VoIP or landline) to register but you can install a desktop app in Chrome/Chromium after that and gives you easy encrypted text and voice messages. There's more to it if you're really concerned about social engineering, man-in-the-middle attacks, malware-infected phones/computers, metadata analysis etc. but it's overkill for you.
That works for everyone where you'd have each other's phone numbers. It's not yet perfect for asymmetric, anonymous or covert relationships like whistleblowers, forming an underground organization, operating in a non-democratic country where using encryption tools is in itself outlawed or dangerous or having a secret identity like being a closeted homosexual, mostly because you're tied to a phone number that binds it all together and burner phones are inconvenient and not available in all parts of the world and it depends on a server in the middle that's trivial to block.
Live today, because you never know what tomorrow brings
HTTPS doesn't hide what computers contacts other computers. I doubt NSA cares that much about the actual content of the communication. By just checking the metadata they can see if someone is communicating with someone on their naughty-list and add them to it. It doesn't matter if you just asked what time it was. If you are talking with a terrorist you are considered to be a terrorist.
The metadata NSA is after is not your computer contacting to facebook.com, it's Alice sending a Facebook message to Bob. They very much want to unwrap HTTPS to get to their level of metadata. And I'm pretty sure they slurped up the content too, because we're the NSA and the rules don't apply to us.
Live today, because you never know what tomorrow brings
The goal is to stop mass surveillance. If GCHQ or the NSA really want that data, they will hack the site anyway.
By using HTTPS everywhere it just makes their job harder, so they can't spy on everyone by default.
Specifically it stops them from 'tapping glass' in places like Room 641a:
* https://en.wikipedia.org/wiki/Room_641A
There are valid reasons for surveillance and wire tapping on individuals; there are few-to-no valid reasons for mass surveillance. HTTPS everywhere stops the latter.
Correct me if I am wrong, but isn't every public server handling TLS connections basically non-secure as a middle man, between a website and someone's web browser?
Surely not to be confused with end-to-end encryption?
There are at least two answers.
Answer 1 - It is E2E and secure against active man in the middle attack:
Browser maintains a list of entities it trusts. Secure websites advertise a certificate blessed by one of those entities. Since an active middleman does not possess secure websites private key it does not have the means to trick browsers into thinking attacking site / proxy was blessed by a trusted entity.
Answer 2 - Answer 1 is in real terms just an illusion:
It is also necessary to consider practically how trust is managed in the real world. Today "blessing" by trusted entities is a completely lights out automated process often relying exclusively on unsecured communications in the areas of naming, addressing and web server probe (e.g. leap of faith) to achieve.
Lets say you have access to see/change traffic to or from a victim server. You can use this access to go to any legitimate SSL provider and rewrite probe requests from this SSL provider to trick it into thinking you have demonstrated ownership of a system you are requesting a certificate for.
You may now leverage your shiny new blessed certificate using your own private key to intercept servers TLS connections with victim browsers having no idea their communications are being compromised.