> That is, a certificate authority like Let’s Encrypt or DigiCert will not be able to provide you with an HTTPS certificate for foo.test or 192.168.0.1 that works with an out-of-the-box client like a major web browser
And they shouldn't. The problem here is using a reserved and internal qualifiers for such things, not the inability[0] of public providers to provide you with such certificate.
> Currently, there’s no canonical way for non-public web services to support HTTPS
Depends on the definition of canonical.
Easy way: just buy the cert from any provider and forget it for a year. Repeat annually.
Easy way but requires automation: use a split-brain DNS setup (either full split or 'semi-split' with your internal resources under a subdomain), request a certificate for a needed FQDN (ie point A record to whatever ACME client you are familiar with), move it to the internal system.
Yes, this doesn't work if your internal resources are 'https://192.168.99.9' and 'mysuperserver.local' (because this is a home network of Average Joe, not a even a homelab of Non-average IT Joe). Back to square one.
> Various people have proposed that browsers support a special mode by which a user can enter a secret that is engraved or displayed on the device to which they want to connect
This can work for a home devices, but the device (or image/text of it's shared secret) should be accessible to everyone, which means anyone can establish a secure connection now. Should it be a concern depends on the usage of such devices.
BTW, WPS does exactly the same [1]
But the most important aspect here lies in the last paragraph of TFA.
I thought that certificates for IP addresses would be a better way to use encrypted SNI rather than DNS hackery. Like onion routing (tor) or extended authentication protocol (EAP) with its outer and inner identities, I envisage the browser would first initiate a TLS connection to the IP address and then initiate a TLS connection to the domain name within the outer TLS connection.
How do you secure your company WLAN in a smaller company?
PEAP-MSCHAPv2 seems to be common, but allows rogue access points / evil twins to steal user credentials. First it requires running a private CA, which is unproportional effort for the part-time IT guy who might be pretty inexperienced in that area.
And worse, how do you make sure that your non-technical or even some sloppy technical users configure their clients to check the CA?
Although interception is not risk free, intercepting MSCHAPv2 does not compromise the credentials.
There is no way to fix that problem because SSIDs are not structured in a way that allows certificates.
Possible fixes would be to allow FQDNs as SSIDs and match these to a certificate, or to require the usercode to contain a domain (like an email address) and verify that. But it’s not in the protocols so that’s a long way off.
> intercepting MSCHAPv2 does not compromise the credentials.
But the cryptography it uses is horrible. A random Web search suggests that Schneier declared it insecure in 1999 and Microsoft in 2004 or so. In the mid 2000s there where commercial services on the Web to recover forgotten Windows NT passwords for $20 or less. (I used it once, worked perfectly). I understand it's the same algorithm. You don't even need to recover the password. You can use the hash you captured to get access later because it is unsalted.
It’s really out of date and the way the system works precludes the use of salts, that’s true. It’s because they want to use the password as a shared secret, but avoid storing the plaintext password on the server and avoid sending the password itself to the server. The protocol is designed for use with file sharing by random untrusted workstations.
The unfortunate end result is that the data stored by the server is a plaintext equivalent. It isn’t easy to recover the original password though unless it’s on a precomputed list, and you can’t get either the password or the encrypted form (that is plaintext equivalent) by watching the network or by posing as the server.
> you can’t get [...] the encrypted form (that is plaintext equivalent) by watching the network or by posing as the server.
Not by watching the network. Because the outer protocol is PEAP, which is similar to TLS I understand. So not completely broken. But when you pose as a server?
Of course the definition of "easy" might vary. What some world-class experts presented at Defcon 9 years ago, is it considered easy?
While I am not the absolute expert and have not really studied the specs I would cautiously claim this is not correct. The outer protocol is PEAP, a variant of TLS. Listening to what is sent inside is impossible in most practical cases.
However, if you are the server (or rogue access point) obviously you see all traffic passing through that tunnel in clear text.
The idea is that the real server has access to the encrypted/hashed version of the password so it can decrypt the communication (and so does the client as the user is entering the password). But a fake server would not have that and thus be unable to decrypt the communication.
That's not how TLS / PEAP works. It's asymmetric cryptography initially (to agree a symmetric key). That's why it's important the client verifies it does not talk to a rogue server.
Yes, that is true. But the information gained by the server if it is rogue is limited, you aren’t directly sending the password. That is the point.
Practically the step of verifying the server is very hard because the client UI doesn’t provide a way; there is no agreement on what the certificate should be.
And they shouldn't. The problem here is using a reserved and internal qualifiers for such things, not the inability[0] of public providers to provide you with such certificate.
> Currently, there’s no canonical way for non-public web services to support HTTPS
Depends on the definition of canonical.
Easy way: just buy the cert from any provider and forget it for a year. Repeat annually.
Easy way but requires automation: use a split-brain DNS setup (either full split or 'semi-split' with your internal resources under a subdomain), request a certificate for a needed FQDN (ie point A record to whatever ACME client you are familiar with), move it to the internal system.
Yes, this doesn't work if your internal resources are 'https://192.168.99.9' and 'mysuperserver.local' (because this is a home network of Average Joe, not a even a homelab of Non-average IT Joe). Back to square one.
> Various people have proposed that browsers support a special mode by which a user can enter a secret that is engraved or displayed on the device to which they want to connect
This can work for a home devices, but the device (or image/text of it's shared secret) should be accessible to everyone, which means anyone can establish a secure connection now. Should it be a concern depends on the usage of such devices.
BTW, WPS does exactly the same [1]
But the most important aspect here lies in the last paragraph of TFA.
[0] which isn't an inability but a unwillingness
[1] https://en.wikipedia.org/wiki/Wi-Fi_Protected_Setup