111–120 of 141 posts
As an example, the NVIDIA driver download pages switch to http:// for the actual downloads although the rest of the site is HTTPS...
It's interesting to see which companies have difficulty keeping up.
TLS 1.3 has been out for a while now, and always promised performance improvements (for example, see this Cloudflare article from Sep 2016: https://blog.cloudflare.com/introducing-tls-1-3/ ). I wonder why Netflix is only getting to it now? Even if some clients didn't support it yet, seems like they could still introduce support on the server side?
Is there a good website listing all the sites that don't use HTTPS or use really old TLS versions? I'm not seeing one. As an example, the NVIDIA driver download pages switch to http:// for the actual downloads although the rest of the site is HTTPS... It's interesting to see which companies have difficulty keeping up.
The elephant in the room is Youtube, which supports only (when last I checked) TLS 1.0. My OpenSSL is configured to fail connections below 1.3, but evidently Firefox bypasses that with its own TLS. If they support TLS at all, why not 1.3? Do they have some dodgy hack that avoids a performance cost in 1.3 that is not in 1.0? Or is it just sloth?
While I really liked that they're moving to fully secure TLS 1.3, I was more impressed by their A/B testing. I find it fascinating they can segment their traffic by device AND then be able to deliver separate streams of content. It's something I've wanted to do at many companies I've worked at but we never had the data to begin with in order to do that. Always another fire to put out...
Earlier quoted context omitted.
DRM is required by the people they licence video from. I imagine that they wouldn't do it if they didn't have to. (They might still do it to their own content but I don't see what they gain by doing it for someone else's)
By now I have only heared about (and experienced) the downsites of DRM. Are there any good arguments for it / casestudies that show any reduction in piracy?
Is there a good website listing all the sites that don't use HTTPS or use really old TLS versions? I'm not seeing one. As an example, the NVIDIA driver download pages switch to http:// for the actual downloads although the rest of the site is HTTPS... It's interesting to see which companies have difficulty keeping up.
Keep in mind such a list wouldn’t necessarily be accurate, especially since proxies like Cloudflare can accept 1.0 and 1.1 connections and convert them to 1.2+ Between the proxy and the server.
I noticed they didn't explicitly mention why they feel the need to ensure authentication+confidentiality+integrity for their streams, given that the data they're dealing with is films and TV shows, rather than, say, payment details. As I understand it, they use HTTPS to prevent spying and data-mining by unscrupulous ISPs. It doesn't affect their DRM at all, which would work just as well over plain HTTP.
Earlier quoted context omitted.
It's possible to distribute large binary blobs over unencrypted HTTP, and to provide security using hash checks. I believe apt no longer does this due to a flaw in their implementation that would not have been an issue if they'd used HTTPS. I'm unsure if Steam still uses insecure HTTP, but they certainly used to. [0] [1] I'm all for HTTPS everywhere, but for Netflix and YouTube, that means encrypting exabytes of data…
How are you distributing the hashes?
Earlier quoted context omitted.
Agreed. I've been blocking HTTP (on port 80) accross my network and I reroute all DNS traffic to a pihole configured to use DoT. At this point in time there is really no reason to let anyone see plain text traffic. A few things are whitelisted but the handful of things that break aren't necessary anyway.
Genuine question: Do you not have issues with browsers and other security products and OCSP? At work they blocked all internet access and tools that forced use of CRL and OCSP lost their minds. Digicert and other CAs seem to to use port 80 for this. Firefox requires OCSP option to be disabled for me for GitHub to work with pauses.
Microsoft Windows, for example, allows administrators to re-publish external CRLs internally, but this only works for the built-in crypto API. Non-native applications generally won't pick this up, including most command-line tools. Blocking outbound port 80 is a mistake.
A colleague said it best: Certificate private keys are like your password. Tell no one, ever. The public key is like your passport. It's safe to hand to a border officer. CRLs are the lists of passport numbers used by known terrorists wanted by Interpol. Preventing the border officer seeing that list just lets the terrorists through the airport. This is never good.
Similarly, most firewalls ship with "drop" as the default rule, which means that a small error in the firewall rules will just end up with 20-120 second timeouts throughout the network. If instead they "rejected" flows with an explicit deny response, this failure mode would be instant and easier to diagnose.
Just yesterday I was trying to diagnose a packet loss issue on a network where some security troll blocked all ICMP between all endpoints. The last time "ping" was used as an attack vector was in the last century, but apparently it's important to prevent any hope of diagnosing entire categories of network issues. Unsurprisingly, their network has atrocious performance, random periods of high packet loss, and asymmetric routing issues. This will not get resolved until the idiot in the security team quits or retires.
PS: I suspect their issue is large UDP packets getting dropped on some paths due to MTU issues. To diagnose this without ICMP in a complex network is basically impossible. The automatic fix is to enable Path MTU Discovery... which requires ICMP!
Every large environment I've been to that has these security trolls in charge with nobody to reign them in was a shitshow of broken systems performing catastrophically badly because they spend 99% of the time waiting for timeouts.
PPS: Why firewalls don't simply have a default, auto-updating rule for "Enable CRL & OCSP outbound" for all known public CAs is beyond me. This is an extremely common requirement, to the point of being practically mandatory for any medium-large enterprise. If you firewall doesn't have this feature, and about a dozen similar ones, you're getting ripped off. You're probably paying some decent fraction of a million dollars for a bag a tools, not a complete solution.