Re:GNU Radio 3.9
by eesmith on Friday January 22, 2021 @05:43PM
(#25877222)
It's taken a while because of work, and trying to research things took time.
I weep for the loss of information. I went to postings of mine from 10+ years ago, to see what would happens in an https-only. Very few of my external links still point to valid resources.
https-only increases link-rot. Of my remaining valid links, many are to non-https sites, because the field I'm in is so specialized and not monetized, so things hang on only because they don't need maintenance. Enforce https-only and they are effectively gone. Here's one - http://www.umass.edu/molvis/francoeur/levinthal/Levinthaltex... . No copies appear anywhere else on a DDG search, though it is in archive.org so not quite perma-death.
Here's a 15 year old code base still going strong http://weblogo.berkeley.edu/ (there's also a v3, also with http).
> If you do not understand any of the steps in my argument, please point them out.
You are correct that I know little about https. Here's the scenario I don't understand, which your explanation doesn't cover:
If I connect to https://MrRadar.server/some/url then at this point my browser knows nothing about it. The MITM server uses a self-signed certificate which expires in one second. My browser will accept it, right? And connect? So the MITM server knows what URL I've tried to connect to?
It then slowly responds with a redirect, taking 1 second, to the same URL (possibly using tricks to prevent the browser from a redirect loop). The self-signed certificate has expired, so the browser doesn't use it, and the second attempt isn't MITM'ed.
This goes through, successfully, right? And there's only a short time where I would see any lock icon? So I have to pay very close attention to see it. And if the attacker times it just right, so the https negotiation is better aligned to the one-second transition, that window is even smaller.
How does https prevent this sort of information leakage?
NOT THAT IT MATTERS, because my corporate site, with https, has only a couple of dozen pages and they are all public so simple traffic analysis lets anyone in the middle know what you are reading from my site. So I "ask you to engage your imagination more vigorously" and wonder if sometime switching to https gives people a false sense that people in the middle can't know which pages they access.
> then the cost of surveilling your site is 0
I believe you mean minuscule, since carrying out the surveillance and storing the data have a cost. Making use of the data has an additional cost.
> negatively impacted
As it turns out, I was negatively impacted yesterday. I made a typo in an email pointing them to my web site (think 'ycombintor.com' instead of 'ycombinator.com'). The quick response was that the site wasn't working. I tried, and got the "Warning: Potential Security Risk Ahead" because that alternate site's certificate was invalid. I spent 5 minutes trying to figure out if my hosting site had messed things up, before I got the followup email pointing out the typo.
Without https, it would have been clear that I got the wrong web site.
(While https, of course, doesn't protect against typo-squatting.)
> Sticking with software so obsolete it cannot interoperate with modern TLS is a choice
Shrug. Forcing everyone to use https is also a choice.
I also mentioned old software stacks. I work with scientific code, some dating back decades, and with little funding for maintenance.
I'm dreading what's going to happen at the end of this month when pip drops support for Python 2.7 causing link-rot to make some old projects no longer work, causing the associated papers to no longer be so easily reproducible.
Part of my work today was to get Docker containers set up with Python 2.7, etc., as a sort of refuge, so those tools would be at hand 5 years from now.
Your 'basic security hygiene' is my archival headache.
> what about if someone inject "alt-right" talking points into your blog?
You've already derided my objection to your characterization. I don't know why you think I've changed my opinion.
> What if someone swapped your contact information
I've already pointed out that I don't see that as a valid security threat.
I mean, someone could break down your door and attack you in the middle of the night - does that threat cause you sleep in a safe room?
Do I also have to worry about them bribing the ops people at my hosting provider?
> What if someone injected a script into your site to DDoS Github[2]?
You mentioned that before. Your [2] says: "in order to execute such an attack, the perpetrator has to create a persistent [cross-site-scripting] DDoS scenario on a very popular website, or ... have control over a very high-traffic proxy - in this case ... the Chinese government's network equipment,"
That is obviously outside of my threat model, in the same way I don't have a safe to store my wallet.
If someone could control the Chinese government's network equipment, couldn't they reroute a lot of https traffic to GitHub to DDoS it?
I weep for the loss of information. I went to postings of mine from 10+ years ago, to see what would happens in an https-only. Very few of my external links still point to valid resources.
https-only increases link-rot. Of my remaining valid links, many are to non-https sites, because the field I'm in is so specialized and not monetized, so things hang on only because they don't need maintenance. Enforce https-only and they are effectively gone. Here's one - http://www.umass.edu/molvis/francoeur/levinthal/Levinthaltex... . No copies appear anywhere else on a DDG search, though it is in archive.org so not quite perma-death.
Here's a 15 year old code base still going strong http://weblogo.berkeley.edu/ (there's also a v3, also with http).
> If you do not understand any of the steps in my argument, please point them out.
You are correct that I know little about https. Here's the scenario I don't understand, which your explanation doesn't cover:
If I connect to https://MrRadar.server/some/url then at this point my browser knows nothing about it. The MITM server uses a self-signed certificate which expires in one second. My browser will accept it, right? And connect? So the MITM server knows what URL I've tried to connect to?
It then slowly responds with a redirect, taking 1 second, to the same URL (possibly using tricks to prevent the browser from a redirect loop). The self-signed certificate has expired, so the browser doesn't use it, and the second attempt isn't MITM'ed.
This goes through, successfully, right? And there's only a short time where I would see any lock icon? So I have to pay very close attention to see it. And if the attacker times it just right, so the https negotiation is better aligned to the one-second transition, that window is even smaller.
How does https prevent this sort of information leakage?
NOT THAT IT MATTERS, because my corporate site, with https, has only a couple of dozen pages and they are all public so simple traffic analysis lets anyone in the middle know what you are reading from my site. So I "ask you to engage your imagination more vigorously" and wonder if sometime switching to https gives people a false sense that people in the middle can't know which pages they access.
> then the cost of surveilling your site is 0
I believe you mean minuscule, since carrying out the surveillance and storing the data have a cost. Making use of the data has an additional cost.
> negatively impacted
As it turns out, I was negatively impacted yesterday. I made a typo in an email pointing them to my web site (think 'ycombintor.com' instead of 'ycombinator.com'). The quick response was that the site wasn't working. I tried, and got the "Warning: Potential Security Risk Ahead" because that alternate site's certificate was invalid. I spent 5 minutes trying to figure out if my hosting site had messed things up, before I got the followup email pointing out the typo.
Without https, it would have been clear that I got the wrong web site.
(While https, of course, doesn't protect against typo-squatting.)
> Sticking with software so obsolete it cannot interoperate with modern TLS is a choice
Shrug. Forcing everyone to use https is also a choice.
I also mentioned old software stacks. I work with scientific code, some dating back decades, and with little funding for maintenance.
I'm dreading what's going to happen at the end of this month when pip drops support for Python 2.7 causing link-rot to make some old projects no longer work, causing the associated papers to no longer be so easily reproducible.
Part of my work today was to get Docker containers set up with Python 2.7, etc., as a sort of refuge, so those tools would be at hand 5 years from now.
Your 'basic security hygiene' is my archival headache.
> what about if someone inject "alt-right" talking points into your blog?
You've already derided my objection to your characterization. I don't know why you think I've changed my opinion.
> What if someone swapped your contact information
I've already pointed out that I don't see that as a valid security threat.
I mean, someone could break down your door and attack you in the middle of the night - does that threat cause you sleep in a safe room?
Do I also have to worry about them bribing the ops people at my hosting provider?
> What if someone injected a script into your site to DDoS Github[2]?
You mentioned that before. Your [2] says: "in order to execute such an attack, the perpetrator has to create a persistent [cross-site-scripting] DDoS scenario on a very popular website, or ... have control over a very high-traffic proxy - in this case ... the Chinese government's network equipment,"
That is obviously outside of my threat model, in the same way I don't have a safe to store my wallet.
If someone could control the Chinese government's network equipment, couldn't they reroute a lot of https traffic to GitHub to DDoS it?