Encrypted web traffic now exceeds 90%
netmarketshare.com
netmarketshare.com
High-quality crypto libraries / systems lead to broader implementation, which makes it harder for elements in mostly-free societies to pressure implementers.
It's one thing for the NSA to quietly lean on ATT (and only ATT). It's a completely different thing for them to quietly lean on 1,000 different organizations and authors.
Similarly, it's easy to sneak a CALEA-alike amendment into national law when only PGP exists. It's harder when the narrative becomes "The government wants to take {beloved product used by millions} away."
I think the second thought doesn't follow from the thought before it. to my experience, the main reason companies don't encrypt is because it's simply makes it that much harder to debug problems and consistently provide successful connections for users. HTTPS can fail in ways that HTTP does not.
If users aren't clamoring for encryption as a feature, the main reason not to provide it is simplicity and quality of service along the axis users appear to care about. If users want encryption enough that they're willing to tolerate that sometimes browser misconfiguration or server side error will cause the connection to fail because it cannot be trusted, then companies will implement it.
It's very carefully written, it does not propose to make a moral judgement about whether the things Snowden revealed are evil only to show that in a technical sense they were an attack and so it made sense for the network to try to mitigate them. Work like D-PRIVE (privacy for DNS) was driven by this concern, and of course it influenced a lot of other work including QUIC.
They’re reading my WhatsApp messages? So what?
I hardly have an answer for that, except for: imagine you’d live in an authoritarian state.
Like when you’re in high-security areas and have to be monitored in the bathroom there might be a door between you and your guard but no real privacy.
Or when people loudly object to strip-searches at the airport but the scanner that sees everything but then only shows a cutout highlighting suspicious areas to pat down are mostly fine.
It's also helpful as we can notify you early if you have some undiagnosed medical issue. You could unknowingly spread your illness to your children without this early detection. We're even able to reduce your monthly health insurance premium by providing this data to the insurance company!
This also enables us to find troubled Individuals before it's too late and address building drug issues before they're full addictions. We'll be able to get them the required attention they need to get back on their feet and be productive members of our society. (Maybe not here though)
It isn't darknet in terms of anonymity; its wildnet in terms of content.
https://en.wikipedia.org/wiki/End-to-end_encryption#Endpoint...
Telegram has faults, I would even argue it has many, but it’s clear that only “secret” chats and voice/video calls are end to end encrypted.
Whatsapp, however, does allow you to download all of your messages from your device using WhatsApp web, and they were recently shown to have an exploit/backdoor in the applications themselves. So in that context they’re comparable in my opinion.
They don't claim e2e encryption by default, they just use some very tricky words that non-technical users will assume as encryption.
From telegram.org:
"Private: Telegram messages are heavily encrypted and can self-destruct."
"Secure: Telegram keeps your messages safe from hacker attacks."
"Encrypt personal and business secrets."
They don't have to. The amount of my peers (i.e. who also major in CS) who think Telegram is more secure than e.g. WhatsApp, is staggering. People don't really think about the protocol, they only think what they hear on the news, or what their buddies think who have heard it in the news.
And what they hear is "Telegram, the new encrypted messaging app, blah bah..." and then they hear debate "Apple.. Encryption.. LEA can't read messages". So the incorrectly count 1+1=3 and think Telegram is safe against LEA.
When you're online and you try to point out Telegram uses home-brew protocol, EXACTLY the same security architecture as Facebook (TLS), and that both are created by Mark Zuckerbergs of separate nations, you'll very quickly drown in fanboys / sock puppets that come with following arguments
"WELL TELEGRAM'S ENCRYPTION HAS NOT BEEN BROKEN IN THE WILD NOW HAS IT???" (no need when you can hack the server and read practically everything)
or
"NOT TRUE TELEGRAM HAS SECRET CHATS" (which only works between mobile clients, and one-on-one chats, just like Facebook Messenger's opt-in end-to-end encryption. Like this one guy on the internet I talked to so eloquently put it: "I don't use secret chats because when I open my laptop, I want to type with my keyboard and not take out my phone every time I want to reply")
or
"PAVEL DUROV ABANDONED MOTHER RUSSIA TO BRING YOU THIS SECURITY" (which tells you absolutely nothing about the protocol and is no proof of any motivation towards any direction. When you're as rich as Durov you can choose any other country in the world and I suspect Dubai isn't treating him too badly).
or
"DUROV REFUSED BACKDOOR SO THERE IS NO WAY TO GET USER DATA" (which is simply not true, it's not like government agents can't hack servers, if Durov could deliver such systems, he'd be making five figure hourly wage hardening Fortune500 companies' systems)
Meanwhile Whatsapp has web interface(sic!) where law enforcement agents can request user specific information and probably chat logs for whatever fake reasons they could come up with.
Telegram is 300mil users and growing.
[1] https://medium.com/@anton.rozenberg/friendship-betrayal-clai...
I guess he has to protect his team. US government tried to bribe his programmers to weaken system security.
Instead, use Matrix (with end to end encryption enabled) or Wire.
1. Bikeshedding has lead to reduction in security agility: Any change will have to be first implemented for the protocol, then to SDKs, then to clients. This progress can take years.
2. Riot is the only client that delivers proper E2EE, majority of clients don't feature it.
3. E2EE is still not enabled by default.
4. IRC-bridges will break E2EE
5. Decentralization does break large silos and make less tempting targets, but now you have a bunch of server admins who have personal relationships with the people the content (when not end-to-end encrypted), and the metadata (always) of which they have access to.
6. Riot's key management and fingerprint verification has been a nightmare. Thankfully this is about to change.
Until all of these are are fixed, i.e.
Until all clients enforce E2EE, until the protocol design is safe enough, until client vendors are required to keep up with security, until no bridges are allowed, until fingerprints are trivial to compare, I will not, and I think no one should Matrix.
(Your opinion of whether Google or Telegram is better will likely also depend upon whether you think malice or incompetence is a bigger threat. Google's business model relies upon it snooping on you, but they have really, really good security people ensuring that nobody else snoops on you. Meanwhile Telegram has less of incentive to actively violate your privacy, but they may let other parties violate your privacy by passively fucking up their engineering. They've done stuff like roll their own crypto algorithms, which is a terrible no-no for anyone that cares about security.)
iMessage can also only guarantee security between the user and Apple due to Apple distributing the public keys (but to a lesser extent because it uses worse crypto), but it does not provide the usability features like searching full chat history across devices that Hangouts does.
1. iMessage uses RSA instead of Diffie-Hellman. This means there is no forward secrecy. If the endpoint is compromised at any point, it allows the adversary who has
a) been collecting messages in transit from the backbone, or
b) in cases where clients talk to server over forward secret connection, who has been collecting messages from the IM server
to retroactively decrypt all messages encrypted with the corresponding RSA private key. With iMessage the RSA key lasts practically forever, so one key can decrypt years worth of communication.
I've often heard people say "you're wrong, iMessage uses unique per-message key and AES which is unbreakable!" Both of these are true, but the unique AES-key is delivered right next to the message, encrypted with the public RSA-key. It's like transport of safe where the key to that safe sits in a glass box that's strapped against the safe.
2. The RSA key strength is only 1280 bits. This is dangerously close to what has been publicly broken. On August 15, 2018, Samuel Gross factored a 768-bit RSA key.
To compare these key sizes, we use https://www.keylength.com/en/2/
1280-bit RSA key has 79 bits of symmetric security. 768-bit RSA key has ~67,5 bits of symmetric security. So compared to what has publicly been broken, iMessage RSA key is only 11,5 bits, or, 2896 times stronger.
The same site estimates that in an optimistic scenario, intelligence agencies can only factor about 1358-bit RSA keys in 2019. The conservative (security-consious) estimate assumes they can break 1523-bit RSA keys at the moment.
(Sidenote: This is very close to 1536-bit DH-keys OTR-plugin uses, you might want to switch to OMEMO/Signal protocol ASAP, at least until OTRv4 protocol finishes).
Under e.g. keylength.com, no recommendation suggest using anything less than 2048 bits for RSA or classical Diffie-Hellman. iMessage is badly, badly outdated in this respect.
3. iMessage uses digital signatures instead of MACs. This means that each sender of message generates irrefutable proof that they, and only could have authored the message. The standard practice since 2004 when OTR was released, has been to use Message Authentication Codes (MACs) that provide deniability by using a symmetric secret, shared over Diffie-Hellman.
This means that Alice who talks to Bob can be sure received messages came from Bob, because she knows it wasn't her. But it also means she can't show the message from Bob to a third party and prove Bob wrote it, because she also has the symmetric key that in addition to verifying the message, could have been used to sign it. So Bob can deny he wrote the message.
Now, this most likely does not mean anything in court, but that is no reason not to use best practices, always.
4. The digital signature algorithm is ECDSA, based on NIST P-256 curve, which according to https://safecurves.cr.yp.to/ is not cryptographically safe. Most notably, it is not fully rigid, but manipulable: "the coefficients of the curve have been generated by hashing the unexplained seed c49d3608 86e70493 6a6678e1 139d26b7 819f7e90".
5. iMessage is proprietary: You can't be sure it doesn't contain a backdoor that allows retrieval of messages or private keys with some secret control packet from Apple server
6. iMessage allows undetectable man-in-the-middle attack. Even if we assume there is no backdoor that allows private key / plaintext retrieval from endpoint, it's impossible to ensure the communication is secure. Yes, the private key never leaves the device, but if you encrypt the message with a wrong public key (that you by definition need to receive over the Internet), you might be encrypting messages to wrong party.
You can NOT verify this by e.g. sitting on a park bench with your buddy, and seeing that they receive the message seemingly immediately. It's not like the attack requires that some NSA agent hears their eavesdropping phone 1 beep, and once they have read the message, they type it to eavesdropping phone 2 that then forwards the message to the recipient. The attack can be trivially automated, and is instantaneous.
So with iMessage the problem is, Apple chooses the public key for you. It sends it to your device and says: "Hey Alice, this is Bob's public key. If you send a message encrypted with this public key, only Bob can read it. Pinky promise!"
Proper messaging applications use what are called public key fingerprints that allow you to verify off-band, that the messages your phone outputs, are end-to-end encrypted with the correct public key, i.e. the one that matches the private key of your buddy's device.
7. iMessage allows undetectable key insertion attacks.
When your buddy buys a new iDevice like laptop, they can use iMessage on that device. You won't get a notification about this, but what happens on the background is, that new device of your buddy generates an RSA key pair, and sends the public part to Apple's key management server. Apple will then forward the public key to your device, and when you send a message to that buddy, your device will first encrypt the message with the AES key, and it will then encrypt the AES key with public RSA key of each device of your buddy. The encrypted message and the encrypted AES-keys are then passed to Apple's message server where they sit until the buddy fetches new messages for some device.
Like I said, you will never get a notification like "Hey Alice, looks like Bob has a brand new cool laptop, I'm adding the iMessage public keys for it so they can read iMessages you send them from that device too".
This means that the government who issues a FISA court national security request (stronger form of NSL), or any attacker who hacks iMessage key management server, or any attacker that breaks the TLS-connection between you and the key management server, can send your device a packet that contains RSA-public key of the attacker, and claim that it belongs to some iDevice Bob has.
You could possibly detect this by asking Bob how many iDevices they have, and by stripping down TLS from iMessage and seeing how many encrypted AES-keys are being output. But it's also possible Apple can remove keys from your device too to keep iMessage snappy: they can very possibly replace keys in your device. Even if they can't do that, they can wait until your buddy buys a new iDevice, and only then perform the man-in-the-middle attack against that key.
To sum it up, like Matthew Green said[1]: "Fundamentally the mantra of iMessage is “keep it simple, stupid”. It’s not really designed to be an encryption system as much as it is a text message system that happens to include encryption."
Apple has great security design in many parts of its ecosystem. However, iMessage is EXTREMELY bad design, and should not be used under any circumstances that require verifiable privacy.
In comparison, Signal
* Uses Diffie Hellman, not RSA
* Uses Curve25519 that is a safe curve with 128-bits of symmetric security, not 79 bits like iMessage
* Uses MACs instead of digital signatures
* Is not just free and open source software, but has reproducible builds so you can be sure your binary matches the source code
* Features public key fingerprints (called safety numbers) that allows verification that there is no MITM attack taking place
* Does not allow key insertion attacks under any circumstances: You always get a notification that the encryption key changed. If you've verified the safety numbers and marked the safety numbers "verified", you won't even be able to accidentally use the inserted key without manually approving the new keys.
So do yourself a favor and switch to Signal ASAP.
[1] https://blog.cryptographyengineering.com/2015/09/09/lets-tal...
> 2. The RSA key strength is only 1280 bits.
This reminds me that in france, unless cryptography is not used for authentication, it is considered a military weapon, and civil usage is restricted in its key strength. Above a certain strength, you technically have to give your key to the government !!...!!!
I don't have a source, but fr.wiki [1] says that in 1999, the government allowed for 128 bit keys to be publicly used without depositing it to the government. It also says that PGP was illegal in france until 1996 (considered a war weapon of category 2, whatever that means).
So I wouldn't be surprised if it were illegal over here to use key strengths above 2048 for end to end encryption in france...
This seems pretty reasonable seen for the whole encyclopedia, but I suppose if you assume that the language change option will just translate the page you're currently looking at then it's quite a surprise.
and WhatsApp allows user to backup/restore their messages with iCloud (unencrypted)
Edit/correction: Neither Wire nor Signal sync conversations that have happened before the setup of a new device to the new device.
This non-technical argument feels more and more a shill talking point because the claimed constraint is NEVER provided with technical arguments.
However, it feels intuitive to non-techies: "End-to-end means only one end and I have many devices therefore I have many ends so I can't end-to-end with every end, so better not end-to-end..."
At best this'd mean the logs are encrypted using the password as the key...
Are you sure the user isn't copying anything between devices? Chat logs and a keyfile maybe?
Telegram isn't great but if your password was used to derive the encryption key, that feature would be entirely feasible.
but getting that through at google must have taken some convincing of various execs, and i'm sure snowden helped with that.
Security is never a binary secure/insecure proposition. There are shades of gray. The key is to use what security you can, but never think "I'm secure now".
As an old mentor once told me: the moment that you think you're secure is the moment that you're at the greatest risk, but you should still lock your door.
https://en.wikipedia.org/wiki/Kazakhstan_man-in-the-middle_a...
- CPUs didn't have hardware acceleration for encryption (AES-NI) like they have today, so activating SSL on your webserver actually decreased your throughput a lot
- It was expensive and complicated to get a certificate for your website, now LetsEncrypt provides them freely and easily
[1] https://www.imperialviolet.org/2010/06/25/overclocking-ssl.h...
Depends on the packets per second being handled. I’ve pegged a CPU core easily doing encryption just a bit over a decade ago due to high data rate. If you’re pushing >500Mb/sec without CPU accelerated encryption (or NIC offloading) it puts a pretty hefty strain on resources.
Quoting https://papers.ssrn.com/sol3/papers.cfm?abstract_id=1591033
“Verisign also operates a ‘Lawful Intercept’ service called NetDiscovery. This service is provided to ‘... [assist] government agen- cies with lawful interception and subpoena requests for subscriber records.’
If you now try to search for NetDiscovery or LEA services for CAs, you won't find any, but I guarantee you they haven't disappeared anywhere.
If you can persuade them to fraudulently vouch for your agency as being some other subscriber then this unavoidably produces a smoking gun which everybody can see, just like when Israel produces fake passports so its agents can travel abroad to murder people.
It doesn't let them passively intercept. The CA could not, gun to its head, help you do that. The mathematics just doesn't work that way, any more than the US Federal Reserve could intervene to make three dollars twice as many as five dollars.
They quickly realized the problems that you describe. In Nov 2011, the Certificate Transparency project by Google had its initial commit: https://github.com/google/certificate-transparency/commit/6a...
In Chrome they have since enforced CT compliance for certificates: https://groups.google.com/a/chromium.org/forum/#!msg/ct-poli...
CT requires that each certificate issued needs to be contained in both a Google log and a non-Google log: https://github.com/chromium/ct-policy/blob/master/ct_policy....
This means that fradulently issued certificates either won't work, or will be contained in public logs run by Google (or Google needs to be forced by authorities as well).
No, it doesn't. If it's signed by my own CA, then I clearly know who signed it. Likewise if it's signed by a CA run by someone else I actually know.
The point of the signing is to have someone I trust validate that the cert they signed is trustworthy even if I don't know the entity that made the cert they signed.
I doubt it’s lying around in Facebooks repositories but I’ve never worked there so cannot say that is the case with certainty.
This is all assuming they are even using modern SSL and are careful with user data. Unfortunately, not a great track record there for FB.
With that background, a motivated employee cannot read WhatsApp messages that they have not sent or received themselves because WhatsApp uses the Signal protocol implementation. Coming to your first question, WhatsApp does share metadata with Facebook. So the fact that content isn’t shared is a moot point because a lot can be inferred from metadata alone to target people for any purpose.
So WhatsApp is not really a secure messenger if Facebook is part of your threat model and is considered an adversary or an adversary who can be easily coerced or compromised.
End-to-end encryption is what is needed, SSL is the bare minimum for everything. It's the seatbelt + airbag. You can't have a car without those anymore. E2EE is the ACC+AEB+ABS. You should not have a car without those anymore.
The public backlash to these revelations is what seems lacking. It had very small political effects, and seemingly very little effect on the NSA. They did not change their stance much, and their weren't really consequences for what the NSA was doing.
got there from official blog https://codebutler.com/2010/10/24/firesheep/
Maybe force https when requesting http ?
https://drive.google.com/file/d/1maSpqYfFoBoCyao14VKzLKPMlm9...
HTTPS adoption has a lot more to do with Google and Mozilla pushing it in their browsers, and Let's Encrypt making getting certificates easy. I have mixed feeling about that - the cost of easy certificates was making spoofing far easier.
I hear this so often about WhatsApp - that they are end-to-end encrypted... But I really have no proof that it's true or that I should trust Zuck.
I am sure you can check the messages being communicated, and on the surface you'll confirm to yourself that messages are encrypted. But how do you know there are no weaknesses in the design? How do you know they didnt "flip the switch" to allow a backdoor?
HTTPS connections are full of 3rd party surveillance systems that still have access to and monitor parts of the cleartext. WhatsApp is connected to the Facebook data vacuum (yes, just "metadata", but as the Snowden revelations you cite show, the metadata is the desirable surveillance records).
If anything, this is a step backwards because it uses the pretense of security while providing none and really just being a fight for exclusive data across multiple corporate surveillance systems.
Remember the "SSL added and removed here" image?
https://thumbs.mic.com/MTBjNTQzNTMzZiMvbWVtejZOdjJsaUdUVkZEa...
Yes, that exact hole was patched, but the point is it wasn't the end of the world that great grandparent implied it would be.
Google moved to fix the problem after the start of the leaks. Pretty quickly (good for them), but after.
Google, Amazon, &tc still store user data uninhibited and though they are often competent about security, they also often provide data to state actors as a normal course of action. The fact the a web browser communicates safely with an endpoint doesn't mean that endpoint isn't a bad apple itself. In some cases these endpoints are logging proxies to other servers and services, and though transport is again encrypted, the data is normally accessible by operators of such services.
Cloud computing has taken away the ownership of data from individuals, and that sounds like it has seeds of some kind of a revolution brewing.
They wouldn't monitor themselves but provide access to law agencies anyhow.
Due to the third-party doctrine [0], they can simply demand access, don't even need a legal warrant. Because there's no reasonable expectation of privacy for data you willingly gave to third parties.
If they want to MITM encrypted traffic they need to demand access from somebody with access to the certificates, who is going to be higher paid and more likely to speak to at least a lawyer before granting access.
These numbers are meaningless without a proper context and can potentially create a "security theater".
There was just an article on the front page today about "I have nothing to hide" and why it's wrong.
Not every communication is about hiding personal stuff.
Absolutely nothing is lost by encrypting the downloaded data as well.
Even if you don't care about what your ISP sees from a privacy standpoint, they still can inject ads or other content into your webpages if the connection isn't secured (at least, from the perspective of your ISP). And this helps prevent attacks against users in coffee shops or other public, unsecured WiFi.
There are good reasons to make all communication, even trivial conversations, secure.
If we only secure "important" communications then we are unnecessarily broadcasting useful meta information to prospective attackers. Encrypted communications rise to the foreground in visibility and that gives away who and when and where sensitive information is shared.
OTOH, if we secure all communication then we make the work of attackers or over-reaching governments much more difficult because no communication clearly says "high value sensitive information"
AFAIK google states (in their privacy policy) they do not do anything with the contents of your emails in a gmail account.
- The good is not the enemy of the perfect.
- This eliminates an entire class of attacks, namely, man-in-the-middle.
- A lot of (most?) user interactions require the server to know what the user wants, and it's unclear how this can happen if the server can't view the user's data.
Sure, they could do it, but it wouldn't be long until there were no Chinese CAs trusted by any browser.
All the non-Google modern CT logs moved to rolling annual logs. Cloudflare's Nimbus for example, is actually logs named Nimbus2019, Nimbus2020, Nimbus2021 and so on. Nimbus2019 is for certificates that expire in 2019. Most of them are already expired 'cos it's November already, it doesn't see a lot of updates, in January Cloudflare can freeze that and eventually they can decomission it, browsers will stop trusting it, but it won't matter because those certs already expired. If you go get yourself a new Let's Encrypt cert now, it'll probably be logged with Nimbus2020, come January 2021 you won't care if Cloudflare freezes it and starts shutting it down.
As a result you need frequent (say, monthly seems fine) updates to stay on top of new logs being spun up and old ones shutting down, or else you'll get false positives.
For CLI or server software that has a regular update cadence anyway I can see this as a realistic choice, for a lot of other software it'll be tough to do this without more infrastructure support.
IF you pin to an intermediate key, which is under the control of a CA, then bad guys who obtain certs from that intermediate will not be inconvenienced by your pin, but these keys are intentionally long-lived (they are protected in an HSM) so the rotation issue isn't as fraught.
CT Logs don't mitigate any of the attacks but they make them very very very visible if they happen. Especially if a CA goes rogue, this will be immediately visible and provable.
Expect-CT only controls if the browser will warn the user if the cert is not in the logs, it does nothing about certs being entered into the CT Logs themselves.
Two things...
Proxies are a thing, and stripping the Expect-CT header is trivial.
Any CA can generate a valid SSL cert for any domain.
Say you have control of the infrastructure and you forge a certificate. You'll have a hard time getting the client to trust the certificate unless you have compromised the signing key of a certificate authority and generated an apparently valid cert.
So, can it entirely prevent it? Can I get verisign to issue me a certificate for G00GLE INC.? If you can alter the client's list of trusted authorities, you can make yourself an authority, but you've already compromised the client. If you can get the server's private certificate, you've compromised the server. You can get creative, sure...probably, you stand a better chance of beating the people in the chain than the technology...but the difficulty of doing so seems to amount to 'mitigation' at the least.
Certificate Transparency exists, solely because any CA can issue an SSL cert for any domain, and use it to MITM via a proxy.
You are trusting every CA out there, not just Verisign. That is the ultimate weakness. Any CA can issue a cert for any domain.
Expect-CT header is the only thing protecting you from a MITM, and it's not even a protection, really, and it's trivial to strip that header as the MITM before proxying to the client.
How do you think mitmproxy[0] works?
Establishing a shared secret with another party over a public channel is not that hard (Diffie-helman, RSA). The hard part is to ensure the other party is who they say they are. Certificates tackle this by having a trusted party (CA) cryptographically bind the shared secret to an identity.
There are issues here, but if you can read and modify the traffic between my PC and the HN servers, you still won't be able to read and modify the traffic.
The binding is over a _public key_ not a _shared secret_.
Also that last sentence is confusing and I'm not sure how best to fix it. Maybe the last word should be 'meaning' not 'traffic' or maybe the word HTTP should be inserted?
> We collect data from the browsers of site visitors to our exclusive on-demand network of analytics and social bookmarking products.
More details about their samples: https://netmarketshare.com/methodology
I would be more inclined to trust sources like https://transparencyreport.google.com/https/overview and Firefox Telemetry which come directly from the browsers. But even these do not count data from mobile apps (most of which have to be encrypted now I think), embedded applications, scripts, and APIs.
Since the end of 2016 on iOS and since Android v9, apps have to communicate over HTTPS. I guess you can technically visit HTTP sites via a browser, but I'd bet that >90% of the traffic from smartphones is over HTTPS.
That isn't true. It is the default but Android lets you override the defaults and use unencrypted traffic both in WebViews and in networking APIs.
Today, the landscape looks more like: You visit Google, click some links that open in AMP (still Google), visit some social networks (primarily Twitter and FB-owned properties). These companies already operate TLS-only, which helps these numbers.
I guess I'm just saying I don't have faith that a system (I'm talking about the intersection of technology, government, and business here) which puts so little power in the hands of individuals will do an adequate job of serving their interests in the long term.
That being said those public WiFi’s shouldn’t be redirecting sites in the first place because for HTTPs sites browsers don’t even let you see the page.
It boggles my mind that we haven't yet agreed on a signaling mechanism at the AP level (DHCP?) for signaling captive portals, as this seems to be quite a common use-case.
I ran into a local store taking credit cards awhile back, no TLS, weird, so I go to the store owner in person. I explain the problem and he insists that can't be the case, he's mad at me. "See! It's got a lock on the website!"... on the homepage. I direct him to the store and now it says Not Secure.
That did more to explain the situation than my attempt at TLS and HTTPS and Certs. He was able to call his web guy and say "It says not secure, Jerry! Fix it".
It was such a simple addition to (at least in Firefox) use the words Not Secure that it's crazy no one thought of it before.
Side topic, but I've been trying to explain to our terrible CFO for years that PCI / PCI DSS is a real thing. He thinks that's the type of regulation that only giant companies have to deal with.
Doesn't matter though, the reality for him was that customers saw a Not Secure and that was a problem. All the crypto, certs, forms, probability of issue, technical things didn't matter, just the perception.
Browsers couldn't have done that if https wasn't free and simple for servers.
At work, we use a paid certificate that is good for a longer period of time (normally a year). So that's one benefit to paying, I suppose.
As far as encryption technologies and security, the traffic encrypted by a lets encrypt cert is just as secure as the traffic secured by a paid-for CA signed cert.
(It's been a bit sinse I went through it but I think it may be as simple as a extra flag in the command to generate the inital cert)
Let's Encrypt could have just as easily generated certificates good for a year or more. But the point of Let's Encrypt is to force you to do this in an automated way, using scripts like you suggest.
You're not getting around anything. The choice was by design.
Sometimes I hear about people just looking for "SSL certificates" because somebody told them that they should have one, and search engines would lead them to those websites; probably that's how it still works.
LetsEncrypt signatures are now trusted by the browsers, so there's usually no need to pay for the service.
There are two halves to the first answer but they're both "Yes, Let's Encrypt is just as secure".
1. Most elements of TLS security have nothing whatsoever to do with certificates. This is easier to grasp in TLS 1.3 than earlier versions (all the encryption in TLS 1.3 is working before anybody sends any certificates anywhere) but it has always been true.
Even without certificates eavesdroppers can't see what was communicated, and nobody can change it en route between client and server. For these things even no certificate at all would be fine...
Certificates do add a vital thing though: Identity. A certificate from Let's Encrypt is a signed document from Let's Encrypt vouching for the identity of your site. Cryptography (with a "private key") lets you prove this certificate belongs to you and nobody else can do that. Without Identity somebody in a position to be an eavesdropper could just pretend to be you and intercept everything (a "Man in the Middle"). So even though it's a small aspect it's vital.
2. To go around issuing people with Certificates you need some way to know who is who. Until a few years ago there weren't many hard and fast rules about how to do this, and so a lot of rather dubious procedures were used by people who charged a pretty penny. Some of them would argue that charging validated the purchaser but that's not so smart, plenty of crooks are willing to spend money to make more.
So, Let's Encrypt actually helped write actual formal rules for how you can make sure you're issuing certificates to the real owners of the names they're certificates for. These are known as the Ten Blessed Methods, because there were once exactly ten of them and each is a method that the certificate issuer is allowed to use to do this Domain Validation. None of them are utterly foolproof, and there is ongoing work to further improve them or get rid of the least effective ones, but at least now there are written rules.
Having helped write these rules it should be no surprise that though they represent a significant tightening up of things for some of the incumbent for-profit issuers, Let's Encrypt was already doing everything required.
Partly this is actually helped by not taking money for certificates. Since Let's Encrypt doesn't make a profit from giving you a certificate, they've no incentive to do so unless they're sure.
Now: For the second part, I have written lengthy answers elsewhere, there are a lot of reasons you might pay somebody money. None of these reasons make Let's Encrypt any worse, and many of them are real niche cases, you'd know about it if you've hit those. Like if you make web sites for Nintendo's obsolete WiiU video game console - Let's Encrypt doesn't help you because the WiiU web browser doesn't have the right trust store for that. Or if you need S/MIME certificates for your corporate email system for some reason, Let's Encrypt don't offer that. If you need a special relationship with your issuer under contract (like Facebook has) then Let's Encrypt can't help you. And so on. For most people it doesn't matter.
If you use a paid CA, someone trying to impersonate you could still go to lets-encrypt and get a certificate there. In other words, the system is only ever as secure as its weakest link. It doesn't matter what link you chose, it matters what link a potential attacker would use.
All of this is because failure of a CA only means false certificates are issued. Its not like lets encrypt ever could get access to any of your private key material.
Most of the major websites fast-tracked HTTPS shortly after that.
I can't count the number of times I've seen the extension page during sign-ups or logins. Oracle Cloud just triggered it the other day during signup and initial login. Most times when I email, asking why an email marketing link, or an embedded token-login email link sends me through an HTTP URL, the person on the other ends tells me they don't know and that's unexpected, or a result of out-sourcing their marketing/email/whatever.
In one case, their marketing mail provider supposedly just blanket intercepted all links and unknown-to-their-customers passed them through an HTTP redirect. Stunningly unprofessional.
Firefox - 80% https://letsencrypt.org/stats/
Google -- 88% on Android; 84% on Windows; 91% on Mac; 73% on Linux https://transparencyreport.google.com/https/overview?hl=en
Seems like it's cyclical thing. DNS over HTTPS is now the big bad technology.
I'm sure there was some substance to it at the time when computers, networks and browsers were slower but I also completely ignored that advice at the time and always used SSL everywhere on sites I set up.
I've never manged a very high traffic site so any extra overhead from SSL was negligible for us.
This meant that MITMs were a lot more effective. Hell, even today Comcast and some other ISPs will MITM you to send notifications when it can do so on a plaintext HTTP connection.
A lot of IT departments also used this to be able to block unwanted traffic and perform monitoring. Now a lot of that relies on DPI techniques like analyzing SNI, or intercepting DNS. DoH and encrypted SNI work together to close both gaps, and widespread deployment of them would largely kill the ability to MITM or monitor consumer devices without modifications.
In modern times the cost of TLS certificates and the overhead of TLS encryption has dropped to effectively zero, so that ship has sailed, and nobody even remembers there was any concern to begin with. Maybe this time, it will be different, due to the lack of other options for MITM.
I imagine in the future there will be similar concerns about protocols that encrypt session layer bits like CurveCP.
We regularly had to tell customers "can you try whether uploading works with this HTTPS link? now it suddenly works? okay, use that link from now on and complain to your network admin/isp"
I'm all for authenticated and encrypted DNS but routing it over HTTPS is just a nasty hack.
HTTP is the internet, and the amount requests a client makes is magnitudes greater than DNS.
Like Google or Cloudfare's DoH isn't slow.
It has made some things more difficult. In the old days when I had problems with a remote IMAP server I could watch each command and response going over the wire. It made troubleshooting dead simple. When a POP3 mailbox got hung up on a single huge message you could just telnet in and delete the offending message in a few seconds. It's crazy to suggest that encrypting everything hasn't made things more complicated than they were. It hasn't been an insurmountable problem, and in an age where everyone wants to sell your browsing habits the rewards have been greater than the pain but it did make things harder.
AFAIK, Wireshark supports decrypting TLS traffic if you give it the private keys.
> When a POP3 mailbox got hung up on a single huge message you could just telnet in
Use “gnutls-cli” or “openssl s_client” – transparent TLS for your terminal. Both those commands also have options supporting protocols’ use of STARTTLS.
Private keys in modern TLS are used only to prove who you are, they aren't used to decrypt anything. Instead random ephemeral secrets are chosen by both sides and a Diffie-Hellman (ECDH) key agreement method is used to agree a shared secret based on those ephemeral secrets.
As a result of this design the connection is encrypted and delivers integrity and confidentiality protection before either side knows who they're talking to.
https://netmarketshare.com/report.aspx?options=%7B%22filter%...
So, upgrading outbound links from http to https (where possible) can be another way to contribute to achieving 100% of the web traffic encrypted.
If a minor CA suddenly issued a cert for, say, mail.google.com, they'd be distrusted by every browser/OS within days. If a government made a habit of doing this, there'd soon be no trusted CAs in their jurisdiction.
The US probably has the best chance of getting away with this since they also have all the major OS/browser vendors in their jurisdiction. But if Mozilla/Apple/Microsoft/Google all mysteriously decided not to distrust a CA that was issuing bogus certs for high-profile sites, it would be pretty conspicuous.
The ability for CAs to issue extra certs to governments to enable MITM has been reduced a lot by CAA and HPKP.
I think I first heard the analogy in Cory Doctorow's presentation The Coming Civil War over General-purpose Computing, which was ironically given at Google. I highly recommend people watch it.
https://netmarketshare.com/report.aspx?options=%7B%22filter%...
It's funny how ever-moving Internet standards mean an Apple II from 40 years ago is more functional than an iMac from 20 years ago.
https://arstechnica.com/information-technology/2015/05/https...
Now I would expect the number to be much closer to 0%.
There will always be an adversary, far powerful than you, with an ability to snoop on your traffic - be it your ISP, the other endpoint, or owners of the infrastructure that you consume, but do not control.
> the other endpoint
It's not sensible to say encrypted web traffic is snooped on by an actor with direct access to the plaintext.
For e.g., even though TLS is end-to-end secure (and I don't doubt that), a website that uses CloudFlare front [1] is susecptible to its secure traffic being intercepted by CloudFlare, because by-design TLS would be terminated at CloudFlare servers'. However, note that the end-user does not notice that, rather he sees his traffic end-to-end encrypted.
[1] https://support.cloudflare.com/hc/en-us/articles/200170416-E...
Keep in mind, this is also true of cloud providers. By running the hypervisor, AWS has full access to your instance's RAM and could snoop on traffic if they pleased.
A compromised service provider is a risk you're accepting unless you own and physically control the hardware terminating TLS. Whether this is an acceptable risk comes down to your threat model. (As do so many things in infosec.)