The paper's claim for Dijkstra's is it's "a single algorithm performs as well as possible for every single graph topology". A* is an augmented version of Dijkstra's only applicable when there is a priori knowledge of a good heuristic for the topology (e.g. manhattan distance in a cartesian plane). Since there is almost certainly no heuristic that is universally optimal for all topologies, A* shouldn't be more universally optimal than Dijkstra's (and can probably perform worse given a bad heuristic).
802.1x allows for the client to validate the authentication server by way of X.509 certificates, although this normally does require manual configuration since there is no global namespace to tie an ESSID to like there is for domain names in normal TLS. Mutual asymmetric key auth is available through EAP-TLS as well, but I could see that being a rare feature on cameras.
Actually, why there is not? Company should be able to just get cert for wifi.company.com and then be allowed to just call its network wifi.company.com...
As of TLS 1.3, the ClientHello (which includes the Server Name Identification (SNI) extension) is still sent in plaintext. There is a current draft for encrypted client hellos[0], but I don't think its adoption is widespread. QUIC appears to encrypt the ClientHello; however, it does not protect from an attacker which can observe the initial connection packets[1].
It is every bit as bad. QUIC streams could map nicely to the SSH model of discrete channels. Sure, you can run it over tcp/443 and have it look like a normal TLS connection to anything that isn't monitoring the traffic patterns, but it's effectively just adding a TLS pipe which only achieves the use of QUIC's congestion control algorithm and handshake but nothing else. I would love to see an SSH implementation which uses QUIC correctly; this isn't it.
MOSH already exists, and it is a proper ssh-like protocol over UDP that takes advantage of the properties of UDP. It's great for use when traveling and being forced to use horrible high latency wireless connections.
MOSH is really a on-purpose "horrible SSH" as far as SSH goes, but it is instead intended to be what you actually need for remote, unstable, unreliable slow connections: a somewhat reponsive experience, a kinda of remote desktop protocol but for terminals, you only send the input and output deltas; you intentionally don't block waiting at any side for precise confirmation of every single byte in or out of a remote terminal.
TLS doesn't matter / isn't needed here right?
The IP address is still in the header from what I understand. So the only thing https can hide is the content, such as a credit card or password that you enter into the site.
The fact that it's a plaintext website that doesn't change means that the exact same information is encoded in simply giving the IP address as there is in knowing that someone looked around the site - because there's nothing else to do?
I would like to learn more about how I am wrong, if I am wrong.
> So the only thing https can hide is the content, such as a credit card or password that you enter into the site.
TLS is not only for hiding the content, it's also for authentication: it ensures that no malicious middle party can modify the content, for instance to inject malicious Javascript (for an example of this happening, read about the "Great Cannon" attack on GitHub).
It also hides what URLs you visited. Depending how the hosting is implemented, just being able to see the IP, or even the domain name, wouldn't show what you were doing, but if it's in plaintext, they can see exactly what pages were visited and files downloaded
I had to look, but in the case of libgit2 yes they have. Like git they have a way to select SHA-1 backends, and the default is the SHA1DC library.
But, even supposing a libgit2 that didn't use SHA1DC I think most users would be protected in practice if the "git" they use used SHA1DC. Hosting providers, local editors etc. use libgit2 for a lot of things, but I think in most cases (certainly in the case of the popular hosting providers) it's some version of "/usr/bin/git" that's handling your push, and actually propagating your objects.
For stopping a colliding hash it's enough that any part of the chain of propagation is able to stop it.
I have found brave to be a decent chromium-based browser for android if the only addon needed is for ad blocking. It has a bottom toolbar provides a similar experience to the firefox bottom address bar.
AUX is for "auxiliary" (aka "misc."/"other") device - i.e. any other bit of unspecified random hardware you'd managed to hook up with a custom driver by yourself.
