Slashdot Mirror
How Far Have We Come With HTTPS? Google Turns On the Spotlight (networkworld.com)
alphadogg writes from an article on NetworkWorld: HTTPS is widely considered one of the keys to a safer Internet, but only if it's broadly implemented. Aiming to shed some light on how much progress has been made so far, Google on Tuesday launched a new section of its transparency report dedicated to encryption. Included in the new section is data highlighting the progress of encryption efforts both at Google and on popular third-party sites. "Our aim with this project is to hold ourselves accountable and encourage others to encrypt so we can make the Web even safer for everyone," wrote HTTPS evangelists Rutledge Chin Feman and Tim Willis on the Google Security Blog.
This is the first time one of these stories have come up and slashdot has had HTTPS enabled!
Better link to "other sites" report: https://www.google.com/transparencyreport/https/grid/?hl=en
Notice that Apple, Bing and Microsoft are all knocked for NOT running a "Modern TLS Config" and NOT using HTTPS by default. (I actually had to check that for myself - it was hard to believe that major companies are still NOT doing HTTPS by default - I enforce this even on my little podunk sites - but it was true!)
Well, not just one problem, but it's a big one, and typically overlooked. It's nice we now encrypt everything, but we're still relying on commercial parties to "verify identity" and to protect us... from anyone they don't take money from. That's a big one, it's fundamental, and it doesn't scale. Worse, any currently in use alternative, like relying on governments, isn't better.
HTTPS isn't that safe. Any agency that can coerce one of the numerous CA's can snoop traffic quite easily. Of course Eric Schmidt is an avid fan of the surveillance society so thats why they weren't going to back anything less centralised than CA-based HTTPS
Forbes.com:
Site works on HTTPS Y
Modern TLS Config N
Default HTTPS N
SNRK...
wait, "Other Top Sites" ?!
the preceding comment is my own and in no way reflects the opinion of the Joint Chiefs of Staff
Google, er, Alphabet didnt really get a rock in their shoe about encryption until Edward Snowden so lets take a moment to thank their engineering consultant in Russia. Once it was revealed that the US government had placed secret taps on links between google datacenters to render their endpoint to service encryption meaningless, the company began working to make the internet a living hell for the surveillance state.
Google owns a browser, so that browser adopted SSL, then TLS as a mandatory connection parameter for google services. a pretty good share of Mozilla, at least in braintrust, is owned by Google and so getting firefox to endorse and enforce encrypted channels to google and other web services was childsplay. after a year, the titty got tougher and HSTS was the norm on some of the largest web content providers on the internet. SSL had been completely phased out for TLS 1.2 and strong AES256 crypto in light of a more concerned review of open source encryption after the governments audacious claim they could break in excess of 80% of encrypted traffic. Libressl hit the scene after some disclosures, DEFCON changed their status with US law enforcement to "its complicated" and now in this foul year of our lord 2016, uncle sams up proverbial shits creek with Apple in what will either be a resounding defeat, or a knock-down drag out multi decade battle at the hands of a corporation with more income and assets than most foreign nations. But slashdot, its only getting good.
googles set their target to the next generation of encryption, elliptic curve, and its looking to be a trend-setter. the primes used by most current elliptic are cooked up by NIST, and NIST has in the past been implicated in weakening encryption as part of US security policy. NIST primes are still used in chrome, but chrome supports Dan Bernsteins Curve25519 alternative that isnt intentionally gimped for uncle sam. Look for Google --and the internet-- to begin using this and other "safe curves" as standards to replace secp384r1 and prime256v1. devices and services in the year of the hoverboard are now shipping with encryption as a requirement, not an option, and features to disable it in browsers have been quietly retired. And perhaps the most resounding confirmation of the internets collective "fuck you" against the carte-blanc collection of data on citizens has come from outside the US. a majority of VPN and encrypted storage providers do not reside within the immediate jurisdiction of Washington.
Good people go to bed earlier.
LUKS can have the container grown (though it's a multi-step process including growing the filesystem after growing the container, there is potential for a good UI to be developed to support this) and has at least one application supporting it on windows.
PAR2 is pretty much the standard for external redundancy. Internal redundancy still risks that a file could be damaged in a way (loss of header) that makes the file unrecognizable, even if it contains redundant blocks inside of it. PAR2 resists this as each blockfile contains its own header with the information needed to rebuild the original file (given sufficient blocks).
7-zip has support across multiple platforms and supports AES-256 encryption including filenames.
What? Did I miss something? Has hell frozen over?
(walks away mumbling something about UTF...)
Of course, that's the ONLY reason why they'd serve over https, right?
It's called LetsEncrypt. You only have to turn over appropriate access to your server to client software (even though to trust it you'd have to review the code or write it yourself). And your web server has to be able to access the LE servers, so you (currently at least) have to permit outbound access from a device providing the website (there are larger configs where you could mitigate that somewhat but this is the simple case).
The client hits the LE servers, gets a string to write to a server-specified location (/.well-known/acme-challenge/URI). Oh, and that retrieval by LE is done over HTTP, so there's NO chance that could ever be subverted.
Google, er, Alphabet didnt really get a rock in their shoe about encryption until Edward Snowden
While I think we should all be very grateful for Snowden's revelations, that's not true. Google was really serious about encrypting everything long before Snowden's revelations.
For example, Gmail was the first major webmail service to provide users the option of only using SSL, back in 2008 or so. Google turned on SSL for web searches in 2011. The design of SPDY, later adopted by the IETF as HTTP2, started around 2010 and from the beginning had no unencrypted mode (though the IETF insisted on adding one).
Once it was revealed that the US government had placed secret taps on links between google datacenters
Google actually started work on encrypting all of those data center links long before Snowden's information came out, though Snowden definitely did light a fire under the project, causing it to get fully deployed very quickly. Snowden probably also had a lot to do with Google's decision to completely disable non-TLS traffic for many of their services (IIRC it was 2014 when gmail and search went TLS-only).
Google owns a browser, so that browser adopted SSL, then TLS as a mandatory connection parameter for google services.
Chrome supported SSL and TLS before Snowden, and ownership of Chrome had nothing to do with making encryption mandatory for Google services, which was done in a browser-agnostic way. Chrome did provide a platform for Google to experiment with other improvements, though, such as certificate pinning, SPDY and QUIC. SPDY and QUIC are mostly about performance, but as I mentioned above Google build encryption into them from the ground up and never even bothered with unencrypted versions.
after a year, the titty got tougher and HSTS was the norm on some of the largest web content providers on the internet.
HSTS also predated Snowden, and Google even started using it for some services before Snowden. But, yes, again Snowden spurred much wider adoption. Which is awesome.
But slashdot, its only getting good.
Indeed. All new Internet protocols and standards now specifically address anti-surveillance in their designs, and lots of academic research is focused on new technologies to make surveillance hard. This is actually an even bigger change than the TLS push, etc., indicates. Prior to Snowden, preventing surveillance was not a design goal. If it happened, it happened by accident. No more. It's now a design goal for much of the tech industry.
An X.509 certificate with multiple subjectAltName entries, sometimes called a UCC, works in all browsers but has two drawbacks. First, a multi-SAN certificate may be more expensive to obtain from a commercial certificate authority. Second, a multi-SAN certificate is designed for multiple sites operated by one entity, not a shared hosting environment with a bunch of unrelated sites behind one IP.
Using multiple certificates on port 443 of one IP address needs Server Name Indication (SNI). This works on both major third-party browsers (Firefox 2 and later and Chrome 6 and later) and all supported pack-in browsers (Safari 4 and later, IE on Windows Vista and later, and Android Browser/Android System WebView on Android 4 and later). The most commonly used browsers without SNI support are IE on Windows XP and Android Browser on Android 2.x, but those have no more than 1% usage share nowadays. I switched my own site away from GoDaddy to a different shared host in the fourth quarter of 2012 for two reasons: GoDaddy openly supported the PROTECTIP bill, and GoDaddy didn't offer SNI at the time.
Use an ACME client to obtain a domain-validated certificate without charge from the Let's Encrypt CA. If you have a VPS or bigger on its own IP address, you can install the official Let's Encrypt client. If you have shared hosting, you can install the sudo-less client, put the resulting ACME response page at the appropriate well-known URL (instead of running sudo python), grab the certificate, and then file a support ticket with your host to get the installed.
Oh yeah google? Really want https everywhere? How about start signing some SSL certs for free to put the mofreking CA mob out of business?
As in the subject line: Why the heck does /. thinks it should be using it. There is absolutely nothing going on here for me, as a reader and occasional poster, to warrant it.
I definitily start to dislike all those "lets go with the times" sites who think that their informative articles, jokes and/or cat videos need to be send over HTTPS only. Where is my choice in the matter ?
Interception (MITM) attacks are only usefull if either side is doing something that needs to be kept secret, and where its value has a meaning. AFAICS nothing /. is doing is of such a value (but if desired posting could be done over HTTPS -- it would be meaningless for AC's though)
It seems you have some grudge against Let's Encrypt, but most of your complaints aren't actually true. To begin with, while the webroot verification you referred to is the most common method, DNS verification is also available as part of the ACME standard, with preliminary (but functional) support implemented in Let's Encrypt. For webroot verification the client software does not need to run on the web server itself; the challenge can be met by manually writing the challenge file to the expected location, or the server could simply forward the well-known URI to some other box running the ACME client software. The reference implementation provides some optional auto-configuration logic to make the setup process easier for first-time users, but you don't have to use it. If you do choose to run the client on the web server it can run as an unprivileged user with write access only to the /.well-known/acme-challenge/ directory. Finally, it doesn't matter that the challenge response is transmitted over HTTP, as the one-time-use response token is not a secret and is only used to demonstrate control over the web server currently servicing requests at the domain name listed in the certificate.
"The state is that great fiction by which everyone tries to live at the expense of everyone else." - Bastiat