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 happy new year to you all
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?
-- Cheers!
A true hero to anyone concerned about internet privacy.
HTTPS is not secure and as long as you use a CA neither are you.
Why doesn't /. have an .onion site?
You can set this up in like 5 mins., and you can generate an 8 char. vanity domain using Garlic in probably an hour or two.
What is the excuse?
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.
At which point is not lets encrypt a conspiracy to reduce the number of sites with self-signed certificates?
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?
Meanwhile CNN and other fake news sites including slashdot don't bother to encrypt.
I hope I did my part by streaming a few terabytes of unencrypted music last year.
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.
which are used by businesses, schools, government agencies, and do-it-yourselfers who don't want to rely on the users to maintain and use an end-point filter. Google and Facebook want you to be able to see their ads at work! There are two known solutions to filtering encrypted content at the border: explicit proxy configured by group policy, or transparent proxy with dedicated certificate authority. Both have reliability and privacy issues.
COE
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.
Noted cybersecurity expert Baron Trump recommends people use carrier pigeons instead.
Many email clients support this, and if you don't trust a CA use self signed certs.
It is the leaking of private host keys via the cloud provider, or physical hardware ME exploits that should be concerning to people.
Those with the keys control the world and all that.
If they can get both the encrypted traffic and the keys then you might as well just go back to plaintext for 9/10s of internet traffic, since outside of online ordering and maybe service passwords the traffic content is already available to the parties you are concerned about.
Really at this point in time what is needed is not encrypted connections, but private key signed javascript, website content, and authentication tokens/session keys. If the server side of that content is all signed offline, the key can remain secure, ensuring the published content is what was uploaded and subverting the mitm threat, provided the site is consistent in key usage and you pinned the signing keys by hostname or URI. This WOULD slow down web publishing since the key would need to be on either an airgapped computer, or some sort of smartcard/tpm device that was only connected during the signing process (and ideally not connected to the network during that time, to reduce chances of malicious code using the signing device to sign a 'mirror script' with their own modifications included.)
Done as stated above the majority of internet malware could be eliminated, end to end encryption would only be required for the semblance of security, and certificate authorities would not need to be implicitly trusted every time, since you would be pinning the scripting key the first time you visited a site, triggering an error the first time either malicious content attempts to be served, or the first time you connect to the 'correct' website if a malicious replacement site's key was pinned instead (the latter of which is already possible with HTTPS, especially in foreign countries/domestic corporations that perform MITM attacks using private CA keys added to the OS keychain and proxy the connections as secure after decrypting them first, which completely mitigates the desired protection AND provides a false sense of security to citizens/employees who are ignorant of the web browser security model's shortcomings.)