95% of the internet traffic is now TLS according to Google:
https://transparencyreport.google.com/https/overview?hl=en
Most of the most severe attacks require HTTP and physical proximity. So weāre fortunate of the huge drive towards HTTPS since Snowdenās 2013 releases when it was around ~55% (Iāve seen the rise in numbers correlated before).
But it also recommends upgrading your router. I wonder how many routers and IoT device companies are actually releasing firmware updates. And quality ones at thatā¦
Those figures are for Google's services, so all those services can do TLS, but some of the clients don't.
However the step change for HTTPS over the wider web is mostly a bunch of related mutually enabling changes:
* Let's Encrypt launches
* Google slightly penalizes plaintext HTTP in search
* Browsers (Chrome, Safari, Firefox at least) stop offering new features outside Secure Context (so HTTPS for public sites) and begin deprecating or reducing scope of some older features outside that context.
On smaller sites also don't underestimate
* Prevalence of browsers/ devices without SNI falls a lot so...
* Many bulk hosting sites begin offering cheap or free HTTPS virtual hosting, with SNI, where previously they only offered IP hosting for HTTPS at higher prices.
In 2005 if I wanted my new one-joke web site to have HTTPS that's a bunch of extra money, for one corny joke, it's not worth it. Today, it's zero extra effort, if I make a new site it has HTTPS by default of course. If I see somebody whose host is trying to charge them money for this, these days it's rarely worth chipping in "You are being ripped off" because somebody else will be typing that already.
TLS is useful and should be the default for everything; However, it is not the protection everyone seems to assume it is for several reasons:
1. Users generally still click "Accept & Continue" when they see certificate warnings.
2. A given app can easily disable certificate validation and blindly trust the other end. For web browsers, great they do it well. Other applications often disable certificate validation altogether. Plenty of mobile apps I've seen fail to do proper certificate validation, though thankfully it is becoming less common thanks to vendor platforms removing the option to be horribly insecure.
3. An attacker can still see which domain names and/or hostnames you're accessing.
The simplest useful thing I could think of with this might be is finding a given WiFi network's IP on the Internet, in those circumstances where the hardware permits you to create your own frames.
> Users generally still click "Accept & Continue" when they see certificate warnings.
I am one of these users. However, that doesn't mean the warning isn't usefulāit puts me on high alert! I enter these websites knowing that I shouldn't trust any information I see, and that I shouldn't enter anything important.
I am of course more technically inclined than the average user, so I don't know that my behavior is broadly applicable. Even so, I wonder if this metric necessarily means what it seems to mean.
> 1. Users generally still click "Accept & Continue" when they see certificate warnings.
In Firefox HSTS blocks this entirely. There is no "Accept" option at all. In Chrome HSTS means the only way to "accept and continue" is to type whatever the current magic bypass phrase is, the ordinary "accept and continue" option isn't there.
And even without HSTS, most web browsers bury the option to continue deep enough that for most users it could as well not exist. In Chrome you have to click "details" and there will be a tiny link to "continue anyway".
I'm already disagreeing with your main point 1)
My parents don't know how to do this and would call me and stop trying to 'solve it'
Chrome and Firefox are quite visual in this regard.
thisisunsafe...
> huge drive towards HTTPS since Snowdenās 2013 releases
Note that HTTPS everywhere in conjunction with HR 4681[1] means there are no limits on how long US government can retain captured communications of US citizens:
> Covered communication.āThe term ``covered communicationāā means any nonpublic telephone or electronic communication acquired without the consent of a person who is a party to the communication, including communications in electronic storage.
> ā¦
> Limitation on retention.āA covered communication shall not be retained in excess of 5 years, unlessā
> ā¦
> the communication is enciphered or reasonably believed to have a secret meaning;
[1]: https://www.nu42.com/2014/12/https-everywhere-and-hr4681.htm...
> the most severe attacks require HTTP
Well, for the services that use HTTP, anyway - there's still a lot of non-HTTP traffic out there like SMTP and DNS. Devices still use SNMP, too, and often connect over wifi.
This particular attack seems difficult in practice. Reassembled fragments still need to yield a checksum-valid frame. With TLS becoming the norm most laptop/mobile/server communication channels will not be affected.
As mentioned in the paper, the problem is indeed that MCUs have become so cheap that every $7 light bulb is equipped with WiFi. The firmware on these devices is almost never updated after production. And even on devices that are being updated, like philips hue, it's often found that WiFi chipsets run their own firmware.
>Reassembled fragments still need to yield a checksum-valid frame.
For a 32bit checksum changing data will give you a 1 in 4,294,967,296 chance of being correct. So just keep bit twiddling some unimportant portion of the frame until you obtain a valid checksum. 4,294,967,296 is not a large number for a modern computer.
These frame checksums are only intended for accidental bit flips. They aren't protection against someone creating fake frames with valid checksums.
What is an MCU?
This is the website with the actual vulnerabilities:
> the design flaws are hard to abuse becauseā¦
This is good.
> in practice the biggest concern are the programming mistakes in Wi-Fi products since several of them are trivial to exploit.
Any indication which devices are known to be affected? None of the pages I've read so far give that information. Though it could be that this information is subject to "responsible disclosure" and won't be released until manufacturers have had a reasonable amount of time to release patches.
All devices are affected, that's why there was a 9-month embargo for Linux. Some vendor devices were silently patched during that period.
All devices are affected by the base flaw as that is part of the protocol as set out from the start.
But if you read the article and others, particularly around the bit I quoted, it essentially states that there are extra, avoidable, flaws in specific devices (or families of devices).
Is this caused by me building my own auth system?
Get a daily email with the the top stories from Hacker News. No spam, unsubscribe at any time.