DanielDent

Much easier to just load a root CA certificate - this use case is explicitly supported and does not require maintaining a browser fork & compile infrastructure.

But "just" doing either of these things turns out not to be simple for many organizations. It's bad enough needing to update your system image/deployment scripts (if you have any!). You also need to figure out what to do about all the devices you don't own. BYOD is a thing.

I believe nossl was intended as a concession for schools that believe in censorship. It makes it relatively easy to configure things so Google doesn't go over SSL so that your existing MITM boxes which censor continue to function as before.

If they continue to support this use case, it may be hard to do without introducing bugs - one exposure to a 'real' service which spits out an HSTS header (or the preload list), and the machine loses the ability to conduct Google searches.

I think they'll either have to use some nasty workarounds, or they'll need to use a different domain - which isn't necessarily something you want to do when you are trying to provide simple rules which allow users to identify phishing.

More likely they'll simply force sites that want to continue to MITM to load their own CA roots.

Although I don't think this is their motivation, it also has the neat side-effect of making Google's Chromebook & device management services more useful.

I bought Veertu through the Mac app store on an early 2009 MacBook Pro. The CPU instructions used for native virtualization are not enabled on the machine. Despite not being compatible with the machine on which I was purchasing, and despite not having documentation on the app store purchase page about the limitations, it let me buy the app - which refused to function. When I requested a refund - after trying multiple times through Apple's horrific broken iTunes refund process - they denied the refund without explanation as to why they did not deem me worthy of a refund for the defective product they sold me.

Possibly if I had the time to spend hours phoning and finding someone to listen I could have gotten a refund.

My takeaway from the experience was a reminder that I was a terrible person for supporting the apple app store business model - a model which inches closer to being mandatory for developers every day.

Interesting, thanks for pointing that out.

This code is such a good example of the potential value of formal verification tools for crypto primitives.

Pretty sure there are planes which are quieter than some bitcoin miners...

That fits with my understanding. What I don't know is how this interacts with the acceleration functionality the chip has. For instance, do the instructions end up being "please do sha256 on this data", or are they closer to AES-NI where it's "please perform one round of an AES encryption flow".

Did you compare performance to SHA512? Despite being a theoretically more secure/"harder" algorithm, on 64 bit platforms it can sometimes be faster than SHA256. If you don't want to use 512 bits, using 256 bits of the output of SHA512 is standardized as SHA512/256 and is considered valid/secure.

(I'm unclear if this performance oddity remains true with the crypto hardware extensions being used here.)

To be fair, OpenStack doesn't exactly have a reputation of "just working". It's really more a framework for building infrastructure. That's why there are entire consultancies and OS distributions to help people successfully deploy OpenStack.

Well, all the IPv6 privacy mechanism does is rotate the /64 suffix. My /64 prefix hadn't changed. From a reputation/risk modelling standpoint, it's usually correct to view a /64 of v6 as a /32 of v4 (i.e. a single address).

"but keep doing stateful tracking of outbound connections just like a NAT would, and drop everything else on the floor"

Here are two important behaviours which come with "just like a NAT would".

1) UPNP - a protocol which allows an application to request it be exposed to the internet

2) Hole punching. E.g. two hosts send packets with matching ip/port values to cause a direct connection to be established between them

Applications don't really do those things on v6...

And, FWIW, ISPs should be giving residential users at least a /56 - if not a /48. Sites should be able to have enough address space to route within the site and still use the features of IPv6 which require a /64. Route aggregation and routing table size is the constraint of the v6 world, not address space.

There's a reasonable argument to be made that router-based firewalls shouldn't be necessary for a home user to have a secure configuration.

If it's not safe to expose a service to the internet, it's also not safe to have it exposed within your LAN without access controls.

NAT-based 'firewalls' can have holes in punched in them in a variety of ways - they are specifically designed to allow holes to be punched, because it's necessary for many applications to work.

It's also possible to take advantage of a user's browser as a relay. Combine that with the ability to use ad networks to target HTML to be served to the IP of an attacker's choosing, and the illusion that a perimeter firewall will prevent an attacker from initiating connections to your network starts to shatter.

I agree that in practice, in many cases today the stateful firewall-like functionality provided by a NAT device will provide a net security improvement. But that's not a situation we should continue to allow.

It's unrealistic to expect users to manually create firewall holes. That's why default configurations tend to include UPNP (which, naturally, introduce a new set of security and DoS concerns) - which will automatically open holes in the 'firewall'.

Google has published some of their thinking on this topic under the 'beyondcorp' moniker. The summary is there is no "safe" and "unsafe" - you need to do a risk evaluation of each attempt to access a service, and "this is coming from inside our network" in inadequate.

I'm unaware of any precedent... I could certainly see people getting upset, but I don't think they'd have solid grounds.

The interesting thing is that I actually am considering setting up a WPAD entry on a domain where I am seeing that traffic, for my own purposes (i.e. unrelated to the random queries I am getting).

In fact, I have just as much an argument that they would be the ones with possible CFAA liability if they start using my proxy server in a way I don't intend.

The CFAA is a mess.

Anything less than 2048 bit is probably a poor choice these days. NIST recommended that RSA-1024 be considered deprecated for use after 2010.

The trouble with RSA is that you end up needing to increase to pretty large key lengths to have significant increases in security after somewhere around 2048 bits. For example, a 4096 bit key is not really as great as it might first appear.

I might be wrong, but I have a vague recollection that Google went with a 16384 bit RSA key for their root key on Chrome devices. It's not a frequently used key (it's used to sign the signing key that can be updated - the signing key uses weaker and faster algorithms which can be changed in new firmware releases), but it's stored in read-only firmware that can only be updated by physically opening a machine. Given that you probably want the key to be good for somewhere between 5 and 30 years, the uncertainty which exists around quantum computers right now, and the tremendous problems which could occur if this key were to be factored, I can understand why they would choose such an obnoxiously large key length.

I wonder how much of a role https://www.toosheh.org/ plays in this decision. Toosheh buys satellite time (funding source: intentionally ambiguous) to transmit curated western media to Iranians.

HN uses Cloudflare (a YC company) and could turn IPv6 on for free with a single click.

But that may not represent the full story for them. Internal moderation and anti-spam may need updating to be compatible with running on two different networks that each have different approaches to numbering.

Even companies that 'get' v6 sometimes have rough edges. E.g. Cloudflare - which has been a great supporter of v6 for a long time now - has been known to send 'log in from a new IP address!' notifications because my machine automatically rotated it's IPv6 privacy suffix.

Even Apple got bit by this issue. They sold an Airport home router which by default provided full v6 connectivity. They were promptly lambasted in the press for "putting their users at risk by not having a proper firewall!". :(

There was a time when perimeter security was seen as an adequate and acceptable technique.

And there are actually some use cases where NAT66 may make sense (various multi-homing and re-numbering avoidance scenarios). I think the jury is still out. I think we'll see lots of NAT66, but for completely different reasons than we've seen v4 NAT.

I do think those uses will tend to involve 1-to-1 prefix translation rather than many-to-1 mapping.

I have heard rumours that, although this is what they state, they actually in practice do assign the entire /64 to the machine. Not sure if this is true and I have not tested it myself.

I see it largely as an attempt to do market segmentation and limit the usefulness of Kimsufi to push people towards their other brands. Unfortunate, but...

DO's v6 needs work. They block port 25, and they don't even assign an entire /64 to a machine, which breaks SLAAC and whole bunch of useful ways of using v6.

It is, however, only 1024 bit RSA for now.

The way I think about IPv6 is that it's an entire second network which happens to frequently coexist on the same layer 1 and layer 2 equipment.

That said, I think there's often a strong argument for only using IPv6 for the internal parts of a network. IPv6 actually simplifies things, and where IPv4 remains needed, it can be encapsulated and routed over a v6 network.

But it takes a team which understands the v6 world and is able to take advantage of the benefits for this to become a reality.

SGC certificates were entirely a result of bizarre US export restrictions.

It's been a while since I read the Mythical Man Month, but as I recall his answer to your point is to look at things through the perspective of systems and subsystems. While Linus is responsible for the overall Linux kernel/system, someone else may be responsible for the X subsystem in the Linux kernel. Which, from what I'm aware, is an accurate representation of how Linux is developed in practice.

This is a well known attack and has been for a while. There are established domain suffixes which block registration for 'wpad' (as well as a few other domains) for exactly this reason. Which is only a partial mitigation in a world where MITM is a potential attack vector.

I have domains which receive a steady stream of 'wpad.$domain' queries from machines which have nothing to do with me. I don't know who owns the machines. I also don't think anyone would notice if I decided to actually provide them with the proxy service they keep requesting from my infrastructure.

A while back Microsoft said that Windows 10 will continue to be free for customers who will benefit from it's assistive technologies. I don't know how they plan to implement this. Many assistive technologies are sometimes helpful to individuals that would not typically be described as 'disabled'.

It seems like such a wide open backdoor to continued free upgrades that it almost looks intentional...

There exist job ads which have the explicit purpose of not finding a qualified candidate. It tends to be a result of things like H1-B visas, union contracts, and other frameworks which provide 'first dibs' on an opportunity to a subset of the global labour pool.

In the US, people have the right to decide a sender may no longer send them snail mail if the sender has sent them obscene materials.

It's my understanding that case laws has led to obscenity in this context being 100% as defined by the recipient. If you believe content type X is obscene, and someone sends you content type X, you can follow the procedure for reporting obscenity. They are obligated to stop sending you anything.

+1 for your userland comment. I think that's a wildly under-appreciated element of UDP encapsulation.

The fine grained control over congestion and congestion logic is cool, sure. But more important in my mind is the fact that there's a cross-platform API available and you can rapidly make changes to how the protocol works without needing to require a specific kernel version or a specific operating system.

There's a whole lot of really cool frameworks for SDN to allow people to work at lower levels, but that's the problem - a standard API that everyone can expect to be widely available hasn't really emerged yet.

At long last, many of the 'hacks' for dealing with the ugly world of NAT etc have become standardized.

E.g. "ICE" provides a negotiation protocol to make a couple arbitrary machines able to talk to each other directly, including the NAT hole punching part of things. In the limited % of cases where there's no known way to punch a hole through NATs, an automatic fallback (using a relay server) is provided as a part of the protocol.

It's not elegant, at least we don't have everybody re-inventing the wheel. And, good results when ICE is used can become part of the criteria now used to judge the quality of NATs and other evil middlebox devices.

[quickly becoming standard comment for me]: IPv6 is in widespread use. IPv6 is not "the future". It's the present. I have services in production where >30% of users access the service over v6. Use is growing. IPv6-only mobile operators are also now a thing.

The idea that middle boxes need to be aware of protocols is incredibly destructive to the end-to-end principal - the critical property of IP networks that enables a rapid pace of permissionless innovation. Middleboxes are evil incarnate.

Fortunately, academic research as well as operational experience has shown that TCP and UDP provide the primitives required to build any protocol. QUIC, which you mentioned, is an example of this. Google has made the explicit - and probably wise - decision to keep protocol state encrypted. While there would be some nice optimizations possible if routers could be aware of things like 'this session is closed now', the risk of middleboxes making it so that the protocol can't continue to evolve is too great. The solution is to specifically prevent middleboxes from having the knowledge needed meddle in an 'intelligent' way.

The last statistics I saw from Google were that 95% of networks don't cause problems for QUIC (i.e. QUIC connections are as fast or faster than HTTP/2). The main issue I'm aware of is not so actually de-prioritization but rather rate limiting (it's often implemented as a quick - and very very dirty - DDoS mitigation technique). Google's stated solution is to fallback to HTTP/2 based on measurements of user experience on a per-AS basis.

Networks which try to be "intelligent" rather than just provide adequate bandwidth will tend towards providing a crappy user experience. Solutions which optimize for well behaved adequately provisioned networks and have an acceptable-though-degraded fallback seems like a reasonable way to promote progress.

SCTP has an RFC-defined UDP encapsulation which will deal with many evil networks.