twitchyliquid64

I've been fairly impressed at Waymo's defensive driving skills, down to it being able to tell when someone turns around towards the road with an eye to cross, & the car slowing-down/giving a wider berth.

We will need to wait and see (i.e. footage) for more facts on this one, but I would caution thinking that Waymo's don't have object permanence capabilities.

(Usual disclaimer around 1st-hand experience etc etc)

A simple fix might be to bind the encrypted value to a PCR (hopefully one that isnt too fragile, but prefs one that measures the initrd) and then to invalidate that PCR when you drop to the recovery shell (by extending some junk bytes to it).

But if you can't find a PCR thats both not too fragile and measures the initrd, then youll have to settle for sealing the encryption key to a fairly static PCR, in which case the attacker could just boot into another OS and then do the right PCR extend dance to get the disk unlock key.

Its the combo of secure boot + disk unlock sealed to a PCR that is meant to get you most of the way there. Agree with other comments that evil-maid style hardware mod attacks are basically impossible to defend against, and practically most ppl attack model this as whether you can pull the disk key in X minutes rather than at all.

Can anyone that knows a thing or two about law comment on section 12 & 13?

Seems like there's... a LOT of calve-outs for due process / checks-and-balances? or is that fairly normal and i'm mis-interpreting in my ignorance?

I stand corrected. Rogue AP / MiTM only needs a AP with the ability to send raw packets, gotcha.

> Many, many websites and APIs don't have HSTS enabled to force all connections to use TLS.

True. Yet another reason for us to push for it.

I have a chrome extension that sets the background-color of all form fields to red if the site it was served on or the ACTION attr are not https.

That said, pretty much every website in my day except for casual reading is pinned to TLS. APIs are the notable exception you pointed out, but otherwise HSTS is quite widely used, and especially effective with preload lists.

> How many thousands of apps dont have this indicator to observe?

Sure there will be some, but your standard Java apache client (along with 99% of the libraries used in Apps) dont have this kind of downgrade behaviour. If they expect validated https, they will fail without it.

> This is a severe vulnerability.

Yepp :D Not the end of the world. I think the main fallacy here is the implicit assumption that the link layer is secure. That has never really been the case and a broken wifi model is merely one more testament to this fact.

On second read, timing requirements arent a thing if you are spoofing the network (obviously) so for that attack vector you don't need specialized hardware. (wont let me edit :( )

You can't preload the whole internet, but by getting the top xx thousand you get 99% of all Chrome users traffic. Its not perfect, but it is very, very effective.

This is not an end-of-the-world type vulnerability.

1. Does not affect long-term credentials - certs, wifi passwords are still safe. Rather, confidentiality (secrecy) from client --> AP is affected, and in some cases packet forgery is possible (integrity).

2. Actually accomplishing this attack, for now, requires special and expensive hardware (med to high range SDR gear). Its also not that reliable outside of a lab environment.

3. Everything you care about _should_ be going over TLS, which mitigates all effects of this attack. If it isnt, fix it.

This is a great moment for you to fire up wireshark and audit the traffic going over your wireless link. If its not adequately protected and you care about it, fix it.

Guess you could say noise is pretty quiet xD

+1 for trying to eliminate complexity from developer error. This was one of the worst cows in the herd for OpenSSL.

That said, I think a bit of good design on the APIs part can go a long way. For Instance, I think Go's crypto/tls aint bad: Its pretty difficult to 'accidentally' configure it in a shocking configuration (suites have to be overridden, turning off verification requires you to set a field called InsecureNoVerify etc).

> What a bunch of senseless FUD.

inb4 strawman arguments and other funzies.

Perhaps you should argue with me on my actual assertion, which is that 'we should use crypto that has stood the test and scrutiny of time'. Do not interpret my criticism as a personal attack.

> already used in production by millions of devices all around the world inside of WhatsApp.

Cool. This is good because that means we have a lot of eyes looking at it.

> formal verification that the crypto is correct in the symbolic model.

This is great and we need more of this kind of work. I don't think its good enough however; most practical attacks rely on side channels, implementation mistakes (formal verification helps in catching these but don't get you all the way), and other obscurities. I stand by my assertion that we should use crypto that has stood the test of time.

> The WireGuard paper itself [3] was presented to the academic community at NDSS

Congrats I guess? relevance?

> not the hastily-made nonsense you imply it is with the phrase "rolled our own crypto"

I made no such implication. 'Roll your own crypto' is a common phrase (at least in my circles) meaning to do it yourself instead of depend on someone else's implementation. Again, I don't see what this has to do with my assertion to use old and battle tested crypto.

> "subnet", tunnels TCP over TCP, which is well known for having pathologically bad performance characteristics

Correct, have a gold star. What does this have to do with crypto?

As you could tell if you scrolled down and read the other discussions around TCP-in-TCP, I am fully aware of the implication of my design decision, and stand by it is the right balance of simplicity, security, and speed (well, thats relative, but for what I was intending it for).

> It also has no binding between certificates and the IP addresses that a certificate is allowed to be inside the tunnel, and, unless I've misread, it allows different peers to hijack each others' IP addresses simply by asking

Correct, I am making the assumption that if posess a private key and cert minted by the server you are trusted. This could be fixed at the cost of additional complexity, loosing the ability for a client to change his address, and less alcohol-time on the developers part. That said, if someone asked me to network together hostile entities, I would have given him some coolaid instead of Go code. But I'm digressing, lets get back on topic.

> But please don't spread FUD about other projects without first understanding them.

I have done no such thing. I stand by my assertion that we should use Crypto that has stood the test of time. Am I not allowed to raise such assertions and discuss them on merit?

Throughput: It depends on the link, but I'm getting 16mbps peak where my connection to my ISP gets me 20mbps peak.

Mobile: You have to use the APIs that are available on the platform to hook into the network layer. After that its pretty straightforward though - you open some TLS connections, do verification, and encapsulate network traffic in some simple structs.

Thanks! This is definitely something I need to get around to once I read up a bit more on vendoring.

I'm glad you're asking these kinds of questions, they need to come up more often especially in a software-supply-chain context.

I am a strong advocate of the saying 'trust but verify'. I believe you should closely audit whatever OSS software you are looking at using in light of your threat model.

To get round to your question: Why should I use subnet over OpenVPN/Tinc etc? That decision is entirely your prerogative. Subnet is small (quick(er) to audit), easy to understand, and has the bare minimum functionality needed to implement a VPN with full mutual authentication. OpenVPN and others have far more features and are almost certainty xx% faster. Where you want to draw the line is up to you.

Correct. While simple, this does have the performance impact you're alluding to. On my 20mbps (down) connection, I peak out at 16mbps on subnet.

The 'double congestion-control' effect can be alleviated by opening 10 or so TLS connections and pumping the packets down those, to spread the effects of TCP congestion control.

My concern is that 'built on modern crypto' and 'reviewed by cryptographers' amounts to 'rolled our own crypto'. IMHO history has shown us time and time again that this is a bad idea - we should use the protocols and ciphers that have stood the test of time. Building subnet using TLS was an architectural choice to avoid playing the role of cryptographer and inevitably getting it wrong.

I'm afraid not :/ Windows is a whole new kettle of fish to get working - you need a device driver to emulate TUN/TAP.

That said, I'm using a library called Water for the low-level networking, and that library just added support for Windows. Implementing full windows support only requires you to implement a few network methods (such as helpers_linux.go) - PRs welcome :)