12 ms·

It's worrying how they are improving the case for "70%" scenarios, while crippling it for the other 30%, without recourse. It's not even funny any more. What h

by j1elo 6y ago

It's worrying how they are improving the case for "70%" scenarios, while crippling it for the other 30%, without recourse. It's not even funny any more. What happens with offline LAN? And the ideal IoT devices that we would all want to have? (I mean those we dream about in all IoT HN posts, where the rants typically are that no internet connection should be needed for most of these kinds of devices) What about offline tutorials? I'd like to provide a ZIP with a plain HTML tutorial that shows how WebRTC works, but users cannot serve it up in their LAN and access through their laptops or phones, because WebRTC requires HTTPS. What's even worse, a self-signed cert doesn't work either. iOS Safari does NOT work with self-signed certs at all! It's maddening, obstacles everywhere once you don't walk the path "they" (industry leaders, focused on mainstream online web services) want you to follow. EDIT: There are some (lots [0]) of features that require a secure context, i.e. a web page served through HTTPS. So the defaults to HTTP are not a silver bullet, and the security exceptions for localhost are not really that useful either, being limited to the same host. [0]: https://developer.mozilla.org/en-US/docs/Web/Security/Secure_Contexts/features_restricted_to_secure_contexts https://developer.mozilla.org/en-US/docs/Web/Security/Secure...

alecbz 6y ago
> without recourse Doesn't the post say they'll fall back to http if the https attempt fails? > For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails. The only change here seems like it's that, from the user's perspective, initial connections to http-only sites will be a bit slower (vs. the opposite which used to be true: initial connections to https-only sites were slower).
- j1elo 6y ago
  I'm talking about the general state of HTTPS implantation. If you develop an offline device which offers a web UI, and it happens to use any feature that is deemed to require a Secure Context, you're out of luck. WebRTC is such a feature, but there are lots more, and they can change from one version of the browser to the next one. The players who are pushing so hard to shove HTTPS down our throats are simply closing their eyes and ignoring the use cases that are not interesting to them. The mandatory renewal timing is a good example: it used to be more than 1 year, now it is 90 days (and some would like to reduce it to mere weeks!) Absolutely great for the grand scheme of things and global security of the Internet, but dismaying for lots of other use cases.
  - dcow 6y ago
    Yeah, I think we need a browser that isn't developed by companies with vested interests in having all your traffic go to them...
    - spurgu 6y ago
      Then again I think Google would do just fine even if Firefox was the only browser.
  - Wowfunhappy 6y ago
    I don't actually see the problem. If you're on a local network, there's no practical way to deal with certificates, so use http. Chrome will fall back. Problem solved. If http support ever gets truly removed, I will be very upset. But that hasn't happened, so what is there to complain about?
    - simias 6y ago
      HTTP is effectively considered legacy by the big web actors these days. More and more APIs are HTTPS-only (often for good reasons) and the "insecure" warnings you get from using HTTP become more intrusive every year. The trajectory is pretty clear, the long term plan is to phase out HTTP completely. And I'm not against it, but I need a solution for LAN devices, and it doesn't exist at the moment because the big web actors do everything in the cloud these days and they don't care about this use case.
      - forgotmypw17 6y ago
        I AM against it, because it puts more centralized censorship power in the hands of the certificate authority. Also, it completely cuts out "legacy" devices, basically anything more than 5 years old. The Web is once again splitting into AOLized mainstream and "indie underground" that you have to make an effort to access.
        chc 6y ago
- xg15 6y ago
  > initial connections to http-only sites will be a bit slower (vs. the opposite which used to be true: initial connections to https-only sites were slower). More than a bit. For HTTPS-only sites, the site could serve a stub HTTP endpoint on port 80 that redirects to HTTPS. The redirect causes maybe some milliseconds to a few seconds (worst case) of latency. HTTP-only on the other hand can't do a HTTPS stub as easily (as the primary reason you'd want HTTP-only is probably that you don't want/can't deal with the certificate management - if you can set up a redirect from HTTPS to HTTP, you might as well go full HTTPS) So the only option for HTTP-only is to not open port 443 at all - meaning Chrome has to wait out the 30 seconds (!) network timeout until it can try the fallback. So pure-HTTP sites would become a lot more unpleasant to use. (A site might be able to cut this short by actively refusing the TCP handshake and sending an RST packet - or by opening and immediately closing the connection. I don't know how Chrome would react to this. In any case, that's likely not what HTTP-only sites in the wild are doing, so they'll need to update their software - at which point, they might just as well spend the effort to switch to HTTPS)
  - zaarn 6y ago
    You can simply send a ICMP Rejected Message, which should direct your browser to immediately try any fallbacks or other hosts. Timeouts occur when you incorrectly configure your firewall to drop packets instead of rejecting.
    - xg15 6y ago
      True, that would work as well. Though I believe it's recommended as a best practice to simply drop packets as not to help port scanners.
      - zaarn 6y ago
        I don't worry about port scanners. If your infrastructure becomes less secure because of a port scanner, it's not very well secured. Sending a REJECT is cheap, no DDoS opportunity and helps browsers and other apps fail over fast. The recommended practise I've heard everywhere is that an ICMP REJECT provides no opportunities for an attacker they wouldn't have with 10 minutes extra time (modern port scanners can be set aggressive enough that REJECT or DROP doesn't matter if they have a known open port they can obtain an ACCEPT timeline from).
EveYoung 6y ago
> IP addresses, single label domains, and reserved hostnames such as test/ or localhost/ will continue defaulting to HTTP. According to the post this shouldn't be an issue.
- j1elo 6y ago
  See my edit. There are lots of stuff browsers forbid you from doing if HTTPS is not in use, so the kind of defaults you quote are not really that useful. For example, the browser won't let you capture webcam video (MediaDevices.getUserMedia()) from a page which is not https or localhost (so, good for a computer where you are running some software, not so good for an embedded device you want to install in your home and access from within your LAN with e.g. your phone, for whatever reasons)
shadowgovt 6y ago
Is it the case that self-signed certs don't work in iOS at all? I'm looking around, and I appear to see tutorials for how to properly configure one in iOS. https://medium.com/collaborne-engineering/self-signed-certificates-in-ios-apps-ff489bf8b96e https://medium.com/collaborne-engineering/self-signed-certif...
- easton 6y ago
  Yeah, I don't know what OP is talking about, I'm using one on my iPhone right now. Enterprises deploy them all the time. It is true, that in recent versions of iOS (in the past five years or so), you have to install the certificate in Safari, then go to Settings->General->About, scroll all the way down, and manually trust the certificate (to ensure you really know what you're doing by enabling it). And iOS doesn't make this known anywhere outside of that special menu three levels deep, I suppose to not confuse people who had an attacker install a cert on their phone somehow.
  - j1elo 6y ago
    If you are talking about installing the Root CA in the iPhone, yeah. That's how I do it in my development devices. But for a user, iOS Safari (not Safari for MacOS) doesn't show any certificate warning that the user can accept, like other browsers. In fact, it just fails absolutely silently. You'd have to connect it to a Mac and open up the developer tools on the desktop's Safari, to see the errors that are being printed on the JS console. Otherwise, you'd just be left wondering why it just doesn't work like all the other browsers.
    - shadowgovt 6y ago
      Unfortunately, user behavior testing shows those certificate warnings are a threat vector. There's a reason the browsers have been moving towards the exits on trusting the user to understand the security model enough to override the trust breakage. Chrome pops a warning, but (with a few exceptions) doesn't let you just navigate through it (there's a secret key sequence you can type to override it, but it's both purposefully undocumented and periodically rotated to make it something that you can only know if you have the chops to read the source code or consult the relevant developers' forums).
throw14082020 6y ago
70% of scenarios? If I were to guess, it would be 70% of your time that your happy with https, and 30% you don't. But its 99.9% or higher in reality. Also, did you know 80% of facts are made up? XD
- j1elo 6y ago
  That number was totally made up, of course :) that's why I quoted it... didn't really want to be too pedant and explicitly say it, but maybe I should have.
  - dan-robertson 6y ago
    But the number matters to your point. Focusing on 70% of users to the detriment of 30% seems a lot less defensible than focusing on 99.9% of users to the detriment of 0.1%. The claim you made was “chrome is hurting a large minority of users and they should make a browser in a more fair way” but this changes when you change your made up numbers to something more like “chrome is hurting a tiny minority of users with weird use-cases like me and I don’t like it” FWIW, it feels like the problem is more that your use-cases don’t fit into web PKI, and I agree with you. But I don’t think harming the security of web browsing for the vast majority is the solution to those problems.
    - Wowfunhappy 6y ago
      > Focusing on 70% of users to the detriment of 30% seems a lot less defensible than focusing on 99.9% of users to the detriment of 0.1%. Ah, but now you’re measuring a different thing than the GP, users vs scenarios! I’d hazard a guess that at least 30% of users need to log into a router at some point or another. I hope it’s more than 30%, because everyone else is likely paying ridiculous prices for a crappy router from their ISP.
      - michaelmrose 6y ago
        I would be substantially surprised if 10% of people had logged into a router EVER and even those folks spend 99.999% of their time on actual websites.
qwertox 6y ago
> It's worrying how they are improving the case for "70%" scenarios, while crippling it for the other 30%, without recourse. It's not even funny any more. I constantly have issues with this address bar hiding the scheme and even the www. One issue is when I quickly want to select some parameters or delete parts of the url in order to "up" one level. What drives me absolutely insane is their inconsitent autocomplete functionality. Sometimes I end up at googling "examp" instead of navigating www.example.com, which was a page I already had visited and therefore showed up as the domain which was autocompleted inside the address bar. Sometimes pressing enter autofills the address, sometimes it googles the halfway typed domain. If I tab the halfway typed domain, it always completes it and an enter will navigate to it. There is some strange difference in entering a domain and performing a search, something feels off. I can't exactly tell what it is, but sometimes I end up with submissions which I did not intend. Also something with pressing the down-key in order to select the topmost entry, the one which gets selected with tab, it just gets skipped when I use the down-key. Another thing is if I want to query "Raspberry Pi disable wifi" or something which begins with "Raspberry Pi", that I then get suggested the URL raspberry.org, a domain which I have often visited, and am forced to type through the entire word Raspberry in order for the URL-functionality to get aborted and have it switch over to googling mode. Maybe there is a keyboard shortcut or something which would help me out, but it simply isn't intuitive.
- NickNameNick 6y ago
  It's a silly hack, but if you install googles "Suspicious site reporter" extension for chrome, then the chrome address bar retains the full URL all the time.
  - comboy 6y ago
    Or you could right click on the address bar and select "Always show full URLs"
  - feross 6y ago
    You can also right click the address bar > "Always show full URLs".
colllectorof 6y ago
>It's worrying how they are improving the case for "70%" scenarios, while crippling it for the other 30%, without recourse. It's not even funny any more. It's even less funny when you realize that the class of devices that gets effectively crippled includes the wast majority of all IIoT devices. Including ones that run manufacturing and power generation. Yeah, your precious personal website is now secure from MITM attacks. The factory that made your car, however, uses critical infrastructure controlled by web interfaces with no encryption at all. Congrats.
staticassertion 6y ago
> It's worrying how they are improving the case for "70%" scenarios, while crippling it for the other 30%, without recourse. It's not even funny any more. 70% of the scenarios impact 99.99% of users as well as the project's intended scenario. > being limited to the same host. Yes, that's the point, of course.
akdor1154 6y ago
I wonder if a scheme could be invented where your router could be responsible for issuing certs to local devices. Forgetting about the impossibilities of industry adoption, would such a scheme be possible? E.g. your router/DHCP controller/AD box gives an IoT device a DHCP ip and maybe a DNS address, and additionally it will provision a cert+key to that device by some standard protocol (keeping this secure might be impossible?). Router has an internal CA cert+key to do this. Your PC then (handwavy) "knows" to retrieve the CA cert of your router by some standard protocol (dhcp extension?), and "knows" to trust it for devices on the router's subnet. Is a scheme like this possible?
- grahamburger 6y ago
  One problem is that it's easy to inject malicious DHCP on to any network you have access to, and you can then route all traffic to yourself (by telling clients that you are the gateway.) This kind of attack is partially mitigated because of TLS - redirecting all traffic to yourself isn't particularly useful if it's all encrypted. But if you could issue a cert along with the DHCP it'd be game over for everyone on the network.
  - midasuni 6y ago
    If you’re the network operator you can mitm network traffic if curse. If you aren’t how are you running a dhcp server when the switch will block the packets?
    - grahamburger 6y ago
      Switches don't typically block DHCP packets. You can literally just spin up your own DHCP server and plug it in to a switch port - if your fake server responds to a DHCP request faster than the legit DHCP server the client will get your lease instead of the right one. It's this way by design - it's not at all uncommon for the DHCP server to not run on the router itself, but on some other device elsewhere in the network, or even outside the layer 2 network using a DHCP Relay.
      - 6y ago
fomine3 6y ago
OpenWRT's story https://lwn.net/Articles/837491/ https://lwn.net/Articles/837491/
wildfire 6y ago
How do the hosts on your local LAN find each other? If via Multicast DNS, what stops you from publishing TLSA records as well?
knorker 6y ago
70% of web servers don't have access to the Internet? Do you have a source on that? I would guess more like 99.99%.

by j1elo 6y ago

alecbz 6y ago

> without recourse Doesn't the post say they'll fall back to http if the https attempt fails? > For sites that don’t yet support HTTPS, Chrome will fall back to HTTP when the HTTPS attempt fails. The only change here seems like it's that, from the user's perspective, initial connections to http-only sites will be a bit slower (vs. the opposite which used to be true: initial connections to https-only sites were slower).

j1elo 6y ago
I'm talking about the general state of HTTPS implantation. If you develop an offline device which offers a web UI, and it happens to use any feature that is deemed to require a Secure Context, you're out of luck. WebRTC is such a feature, but there are lots more, and they can change from one version of the browser to the next one. The players who are pushing so hard to shove HTTPS down our throats are simply closing their eyes and ignoring the use cases that are not interesting to them. The mandatory renewal timing is a good example: it used to be more than 1 year, now it is 90 days (and some would like to reduce it to mere weeks!) Absolutely great for the grand scheme of things and global security of the Internet, but dismaying for lots of other use cases.
- dcow 6y ago
  Yeah, I think we need a browser that isn't developed by companies with vested interests in having all your traffic go to them...
  - spurgu 6y ago
    Then again I think Google would do just fine even if Firefox was the only browser.
- Wowfunhappy 6y ago
  I don't actually see the problem. If you're on a local network, there's no practical way to deal with certificates, so use http. Chrome will fall back. Problem solved. If http support ever gets truly removed, I will be very upset. But that hasn't happened, so what is there to complain about?
  - simias 6y ago
    HTTP is effectively considered legacy by the big web actors these days. More and more APIs are HTTPS-only (often for good reasons) and the "insecure" warnings you get from using HTTP become more intrusive every year. The trajectory is pretty clear, the long term plan is to phase out HTTP completely. And I'm not against it, but I need a solution for LAN devices, and it doesn't exist at the moment because the big web actors do everything in the cloud these days and they don't care about this use case.
    - forgotmypw17 6y ago
      I AM against it, because it puts more centralized censorship power in the hands of the certificate authority. Also, it completely cuts out "legacy" devices, basically anything more than 5 years old. The Web is once again splitting into AOLized mainstream and "indie underground" that you have to make an effort to access.
      - chc 6y ago
xg15 6y ago
> initial connections to http-only sites will be a bit slower (vs. the opposite which used to be true: initial connections to https-only sites were slower). More than a bit. For HTTPS-only sites, the site could serve a stub HTTP endpoint on port 80 that redirects to HTTPS. The redirect causes maybe some milliseconds to a few seconds (worst case) of latency. HTTP-only on the other hand can't do a HTTPS stub as easily (as the primary reason you'd want HTTP-only is probably that you don't want/can't deal with the certificate management - if you can set up a redirect from HTTPS to HTTP, you might as well go full HTTPS) So the only option for HTTP-only is to not open port 443 at all - meaning Chrome has to wait out the 30 seconds (!) network timeout until it can try the fallback. So pure-HTTP sites would become a lot more unpleasant to use. (A site might be able to cut this short by actively refusing the TCP handshake and sending an RST packet - or by opening and immediately closing the connection. I don't know how Chrome would react to this. In any case, that's likely not what HTTP-only sites in the wild are doing, so they'll need to update their software - at which point, they might just as well spend the effort to switch to HTTPS)
- zaarn 6y ago
  You can simply send a ICMP Rejected Message, which should direct your browser to immediately try any fallbacks or other hosts. Timeouts occur when you incorrectly configure your firewall to drop packets instead of rejecting.
  - xg15 6y ago
    True, that would work as well. Though I believe it's recommended as a best practice to simply drop packets as not to help port scanners.
    - zaarn 6y ago
      I don't worry about port scanners. If your infrastructure becomes less secure because of a port scanner, it's not very well secured. Sending a REJECT is cheap, no DDoS opportunity and helps browsers and other apps fail over fast. The recommended practise I've heard everywhere is that an ICMP REJECT provides no opportunities for an attacker they wouldn't have with 10 minutes extra time (modern port scanners can be set aggressive enough that REJECT or DROP doesn't matter if they have a known open port they can obtain an ACCEPT timeline from).

EveYoung 6y ago

> IP addresses, single label domains, and reserved hostnames such as test/ or localhost/ will continue defaulting to HTTP. According to the post this shouldn't be an issue.

j1elo 6y ago
See my edit. There are lots of stuff browsers forbid you from doing if HTTPS is not in use, so the kind of defaults you quote are not really that useful. For example, the browser won't let you capture webcam video (MediaDevices.getUserMedia()) from a page which is not https or localhost (so, good for a computer where you are running some software, not so good for an embedded device you want to install in your home and access from within your LAN with e.g. your phone, for whatever reasons)

shadowgovt 6y ago

Is it the case that self-signed certs don't work in iOS at all? I'm looking around, and I appear to see tutorials for how to properly configure one in iOS. https://medium.com/collaborne-engineering/self-signed-certificates-in-ios-apps-ff489bf8b96e https://medium.com/collaborne-engineering/self-signed-certif...

easton 6y ago
Yeah, I don't know what OP is talking about, I'm using one on my iPhone right now. Enterprises deploy them all the time. It is true, that in recent versions of iOS (in the past five years or so), you have to install the certificate in Safari, then go to Settings->General->About, scroll all the way down, and manually trust the certificate (to ensure you really know what you're doing by enabling it). And iOS doesn't make this known anywhere outside of that special menu three levels deep, I suppose to not confuse people who had an attacker install a cert on their phone somehow.
- j1elo 6y ago
  If you are talking about installing the Root CA in the iPhone, yeah. That's how I do it in my development devices. But for a user, iOS Safari (not Safari for MacOS) doesn't show any certificate warning that the user can accept, like other browsers. In fact, it just fails absolutely silently. You'd have to connect it to a Mac and open up the developer tools on the desktop's Safari, to see the errors that are being printed on the JS console. Otherwise, you'd just be left wondering why it just doesn't work like all the other browsers.
  - shadowgovt 6y ago
    Unfortunately, user behavior testing shows those certificate warnings are a threat vector. There's a reason the browsers have been moving towards the exits on trusting the user to understand the security model enough to override the trust breakage. Chrome pops a warning, but (with a few exceptions) doesn't let you just navigate through it (there's a secret key sequence you can type to override it, but it's both purposefully undocumented and periodically rotated to make it something that you can only know if you have the chops to read the source code or consult the relevant developers' forums).

throw14082020 6y ago

70% of scenarios? If I were to guess, it would be 70% of your time that your happy with https, and 30% you don't. But its 99.9% or higher in reality. Also, did you know 80% of facts are made up? XD

j1elo 6y ago
That number was totally made up, of course :) that's why I quoted it... didn't really want to be too pedant and explicitly say it, but maybe I should have.
- dan-robertson 6y ago
  But the number matters to your point. Focusing on 70% of users to the detriment of 30% seems a lot less defensible than focusing on 99.9% of users to the detriment of 0.1%. The claim you made was “chrome is hurting a large minority of users and they should make a browser in a more fair way” but this changes when you change your made up numbers to something more like “chrome is hurting a tiny minority of users with weird use-cases like me and I don’t like it” FWIW, it feels like the problem is more that your use-cases don’t fit into web PKI, and I agree with you. But I don’t think harming the security of web browsing for the vast majority is the solution to those problems.
  - Wowfunhappy 6y ago
    > Focusing on 70% of users to the detriment of 30% seems a lot less defensible than focusing on 99.9% of users to the detriment of 0.1%. Ah, but now you’re measuring a different thing than the GP, users vs scenarios! I’d hazard a guess that at least 30% of users need to log into a router at some point or another. I hope it’s more than 30%, because everyone else is likely paying ridiculous prices for a crappy router from their ISP.
    - michaelmrose 6y ago
      I would be substantially surprised if 10% of people had logged into a router EVER and even those folks spend 99.999% of their time on actual websites.

qwertox 6y ago

> It's worrying how they are improving the case for "70%" scenarios, while crippling it for the other 30%, without recourse. It's not even funny any more. I constantly have issues with this address bar hiding the scheme and even the www. One issue is when I quickly want to select some parameters or delete parts of the url in order to "up" one level. What drives me absolutely insane is their inconsitent autocomplete functionality. Sometimes I end up at googling "examp" instead of navigating www.example.com, which was a page I already had visited and therefore showed up as the domain which was autocompleted inside the address bar. Sometimes pressing enter autofills the address, sometimes it googles the halfway typed domain. If I tab the halfway typed domain, it always completes it and an enter will navigate to it. There is some strange difference in entering a domain and performing a search, something feels off. I can't exactly tell what it is, but sometimes I end up with submissions which I did not intend. Also something with pressing the down-key in order to select the topmost entry, the one which gets selected with tab, it just gets skipped when I use the down-key. Another thing is if I want to query "Raspberry Pi disable wifi" or something which begins with "Raspberry Pi", that I then get suggested the URL raspberry.org, a domain which I have often visited, and am forced to type through the entire word Raspberry in order for the URL-functionality to get aborted and have it switch over to googling mode. Maybe there is a keyboard shortcut or something which would help me out, but it simply isn't intuitive.

NickNameNick 6y ago
It's a silly hack, but if you install googles "Suspicious site reporter" extension for chrome, then the chrome address bar retains the full URL all the time.
- comboy 6y ago
  Or you could right click on the address bar and select "Always show full URLs"
- feross 6y ago
  You can also right click the address bar > "Always show full URLs".

colllectorof 6y ago

>It's worrying how they are improving the case for "70%" scenarios, while crippling it for the other 30%, without recourse. It's not even funny any more. It's even less funny when you realize that the class of devices that gets effectively crippled includes the wast majority of all IIoT devices. Including ones that run manufacturing and power generation. Yeah, your precious personal website is now secure from MITM attacks. The factory that made your car, however, uses critical infrastructure controlled by web interfaces with no encryption at all. Congrats.

staticassertion 6y ago

> It's worrying how they are improving the case for "70%" scenarios, while crippling it for the other 30%, without recourse. It's not even funny any more. 70% of the scenarios impact 99.99% of users as well as the project's intended scenario. > being limited to the same host. Yes, that's the point, of course.

akdor1154 6y ago

I wonder if a scheme could be invented where your router could be responsible for issuing certs to local devices. Forgetting about the impossibilities of industry adoption, would such a scheme be possible? E.g. your router/DHCP controller/AD box gives an IoT device a DHCP ip and maybe a DNS address, and additionally it will provision a cert+key to that device by some standard protocol (keeping this secure might be impossible?). Router has an internal CA cert+key to do this. Your PC then (handwavy) "knows" to retrieve the CA cert of your router by some standard protocol (dhcp extension?), and "knows" to trust it for devices on the router's subnet. Is a scheme like this possible?

grahamburger 6y ago
One problem is that it's easy to inject malicious DHCP on to any network you have access to, and you can then route all traffic to yourself (by telling clients that you are the gateway.) This kind of attack is partially mitigated because of TLS - redirecting all traffic to yourself isn't particularly useful if it's all encrypted. But if you could issue a cert along with the DHCP it'd be game over for everyone on the network.
- midasuni 6y ago
  If you’re the network operator you can mitm network traffic if curse. If you aren’t how are you running a dhcp server when the switch will block the packets?
  - grahamburger 6y ago
    Switches don't typically block DHCP packets. You can literally just spin up your own DHCP server and plug it in to a switch port - if your fake server responds to a DHCP request faster than the legit DHCP server the client will get your lease instead of the right one. It's this way by design - it's not at all uncommon for the DHCP server to not run on the router itself, but on some other device elsewhere in the network, or even outside the layer 2 network using a DHCP Relay.
    - 6y ago

fomine3 6y ago

OpenWRT's story https://lwn.net/Articles/837491/ https://lwn.net/Articles/837491/

wildfire 6y ago

How do the hosts on your local LAN find each other? If via Multicast DNS, what stops you from publishing TLSA records as well?

knorker 6y ago

70% of web servers don't have access to the Internet? Do you have a source on that? I would guess more like 99.99%.