pfg

I'm far from an FFmpeg expert, but I believe it's possible to segment the input video, transcode the segments one by one, and then concatenate them. Not sure how the segmentation and concatenation steps perform, but if that's fast, this might even improve your overall transcoding speed due to the parallelization.

You're free to do anything with the source code that's permitted by the Apache license, including commercial usage. The commercial licensing only affects the binaries offered on the site.

Are you sure? The initial post was about .dev being HSTS-preloaded, but the comment I was replying to was an answer to the suggestion that they could use self-signed certificates after importing them to the trust store.

Firefox will happily accept self-signed certificates chaining to manually imported CAs. However, there are a lot of severely outdated guides on creating self-signed certificates out there, and many of the certificates produced that way won't be accepted by any modern browser. OpenSSL's terrible command-line UX certainly doesn't help matters. I've found easypki[1] to be the most convenient tool for this purpose.

[1]: https://github.com/google/easypki

Presumably to demonstrate that a phishing site using such a certificate would be visually indistinguishable from the targeted site.

By "site", are you referring to the actual site, or the EV indicator? Because the site itself doesn't look anything like Stripe's[1].

[1]: https://stripe.ian.sh/

Pretty much any non-obfuscated PoC that anyone could come up with for this vulnerability would be trivial to adapt to run malicious code. This doesn't really lower the bar for anyone, and as long as there's no malicious payload, it doesn't seem legally or morally wrong.

(This is not to say that you couldn't end up in a situation where you'll spend a few years and a truckload of money in a legal fight because you've released something like this.)

I'm not sure why you think GitHub ought to take down code for a proof of concept.

The code is released under the Apache License. You're free to compile the source code and use it commercially. You're not allowed to do that with the official binaries.

This is under the assumption that CAs fail closed when they encounter DNSSEC errors (which, by some interpretations, is mandatory according to the Baseline Requirements).

Merely hijacking the authoritative DNS for a domain does not defeat DNSSEC, which chains from the root to TLDs to registered domains. In other words, and assuming all CAs are perfect w.r.t DNSSEC, you cannot spoof a "No CAA record here" response for a DNSSEC-enabled domain merely by hijacking the authoritative DNS or a resolver.

The difference between HSTS, Expect-CT and HPKP is that the former two offer a way out (support HTTPS, provide qualified SCTs) whereas HPKP can effectively brick your domain for a couple of months, and it's not even hard to pull off.

Presumably that's fairly new. The domain hasn't made it on the HSTS preload list shipped by browsers yet, so my guess would be they started using HSTS in response to this attack.

One could argue that in a perfect world the combination of DNSSEC and CAA should stop attacks of this nature. However, this only holds up under a rather limited set of circumstances:

1. The targeted domain would need to make use of both DNSSEC and CAA in the first place. I doubt that's true for more than a tenth of one percent of all domains out there.

2. The attackers would have to only target DNS resolution, and not the IP ranges hosting the targeted domain itself.*

3. Every single CA out there would have to follow the Baseline Requirements to the letter and fail closed for DNSSEC-enabled domains.†

I'm not sure if that makes for a good argument in favour of wading into the cesspit of DNSSEC.

* By targeting the IP ranges the site is hosted at, rather than the authoritative DNS, an attacker would be able to complete a "Agreed-Upon Change to Website" challenge as defined in the Baseline Requirements (http-01 in ACME). There's work being done to somewhat mitigate this by extending CAA to support whitelisting domain validation methods.

† From what I recall, when researchers looked into this this shortly after CAA became mandatory for CAs, a number of CAs were found to have issues with DNSSEC enforcement. Additionally, some argued the language in the Baseline Requirements regarding CAA and DNSSEC was quite ambiguous.

To be more precise, it would be a problem if GitHub got an Extended Validation certificate with the organization field containing the name of the domain owner rather than GitHub itself.

It would in fact be perfectly fine for a CA to issue an EV certificate containing "GitHub, Inc." and a domain that GitHub does not actually own, but which they control because someone pointed their A or CNAME record to GitHub pages. The Extended Validation Guidelines[1] do not require domain ownership for the organization requesting the certificate, it's enough to control it in a way that allows you to complete one of the blessed validation mechanisms defined in the Baseline Requirements.

[1]: https://cabforum-travis-artifacts.s3-us-west-2.amazonaws.com...

> I also can't remember whether there's an API for legitimate owners to revoke a cert issued to someone else that's no longer OK. Let's Encrypt does have to be able to do that, but if there's no API it might be very manual.

You can do that by going through the usual challenge process in ACME and obtaining an authorization object for all names on a certificate. Any ACME account who is authorized to issue certificate for these names can also request revocation for existing certificates (even if owned by different ACME accounts).

(You're a bit screwed if the certificate you want to revoke also contains names from other users. This is a good argument for a "one name per certificate" or "only the names of one user per certificate" policy for such implementations.)

I'm not exactly sure what your threat model is, then. The typical way this gets deployed is with U2F USB devices with non-extractable keys. "Access to all keys" is not exactly technically feasible.

If your concern is "well, there's always the admin/support backdoor", i.e. a compromised admin account or a social engineering attack on support personell could lead to attacker-controlled keys being enrolled, I'm afraid that's not really something you can solve by just throwing new technology at the problem. However, you'll definitely make it harder to even get to the point where admin accounts are compromised by rolling out U2F or webauthn.

Personally, I'm perfectly fine with a technical solution that solves phishing for everything but the most advanced social engineering campaigns.

webauthn helps with phishing in the same way that U2F does: by binding the keys to specific domains/origins. A phishing site hosted at gmailsecurelogin.com can still steal your password, but the security key is not going to produce anything that's usable on mail.google.com as a second factor.

SNI is part of the first message a TLS client sends to the server - the Client Hello. TLS clients that support SNI (including all modern browsers) will typically always send the SNI extension, regardless of whether the server supports or makes use of SNI.

There's a fee of $0.50 per hosted zone and month for Route 53, in addition to the $0.40 per million queries. This is optional if you don't want to use Route 53 for DNS, so you can still use a free option like Cloudflare instead.

Would you recommend going with Go's crypto/tls if you can get away with it?

MesaLink relies on ring for its crypto operations. Ring is written in a mix of Rust, C and assembly, with most of the C and assembly code coming from (Boring|Open)SSL.

Cloudflare would be another example of a large-scale BoringSSL user (with some changes for things like OCSP).

You're still leaking that information due to SNI.

Publicly-trusted CAs can issue trusted certificates for IP addresses. It's simply far less commonly used, and most CAs either don't offer it at all or only for enterprise clients.

(You might have been thinking about issuance for IP addresses in private/reserved IP space. That is indeed prohibited nowadays, just like "internal names", i.e. domains that don't end in a public suffix.)

It's worth noting that Chrome has plans to deprecate header-based pins in a few months and static pins (the ones baked into binaries) at some point after their Certificate Transparency policy covers all non-expired certificates. That'll make Firefox the only mainstream browser with HPKP support. (Mozilla hasn't announced their intentions so far.)

By "verifying who controls the IP space", do you mean verifying control over the IP a domain resolves to? In that case, what you're missing here is that control over DNS lets you alter that IP address to whatever you'd like. The attacker will have no difficulty demonstrating control over an IP address they own.

The email address is optional, though most clients tend to hide that fact (or make it mandatory).

There's a couple of things to keep in mind. First, all major browsers (and many other TLS clients too) have been using SNI for more than a decade now, so it's not so much that TLS 1.3 makes things worse, it just better reflects the implementation reality. Second, even in a hypothetical world without SNI, anyone watching the traffic would still see the IP the client is talking to. For a large percentage of web traffic, that IP address can easily be associated with exactly one domain, and for the rest - shared web hosts, things behind CDNs, etc. - you still have the response size to work with, which you can use to make a fairly good guess as to what the domain is.

Of course it's usually even simpler than that because you can just look at DNS lookups which overwhelmingly don't use transport-level encryption today.

Based on what my own tests have shown, it seems that Netlify serves content from EC2 instances in the AWS region that's closest to the visitor (presumably using NS1's Geo Routing). That definitely results in better performance compared to a site served from a single data center or S3 bucket, but it can't quite keep up with CDNs with hundreds of PoPs like Cloudflare or Fastly (which is what GitHub pages runs on). For me, the convenience of Netlify won out over the still relatively minor performance impact.

(IIRC Netlify also has an option you can enable to serve some assets via CloudFront, so that should speed things up for subresources.)

I'm not saying that you need to grant any kind of permission in order to use U2F tokens, but rather that a user thinking "I want to login to Google" and "I need to use that USB key thingy to do that" is quite likely to accept a prompt that requests access to the U2F device.