7 ms·

Not that scary when you remember there are some systems that haven't been significantly updated for decades (e.g. the Linux TTY interface). A lot of stuff can j

Not that scary when you remember there are some systems that haven't been significantly updated for decades (e.g. the Linux TTY interface). A lot of stuff can just coast indefinitely, you'll get quirks but people will find workarounds. Also this is kind of why everything is ever so slightly broken, IMHO.

yjftsjthsd-h 3y ago
That only helps if it stays static. For example, if the Linux TTY interface was unchanged for decades to such a degree that nobody worked on it, but then had a vulnerability, who would be able to fix it quickly?
- ironmagma 3y ago
  Perhaps someone with more knowledge can chime in. But, my impression is that there are vulnerabilities with TTY, it's just that we stay educated on what those are. And we build systems around it (e.g. SSH) that are secure enough to mitigate the effects of those issues.
  - codetrotter 3y ago
    SSH was a replacement for Telnet. But any weaknesses at the TTY level is orthogonal to that, right? Unless you mean, having thin clients use SSH as opposed to directly running serial cables throughout a building to VT100 style hardware terminals, and therefore being vulnerable to eavesdropping and hijacking? But I think when we talk about TTY we mostly don’t refer to that kind of situation. If someone talks about TTY today, I assume they mean the protocol and kernel interfaces being used. Not any kind of physical VT100 style serial communication terminals.
    - tingletech 3y ago
      I miss rooms of green and amber screen terminals hooked up via serial cable. As an undergrad I remember figuring out how to escape from some menu to a TTY prompt that I could somehow telnet to anywhere from. Later, I would inherit a fleet of 200 of them spread across 12 branch libraries. I can't remember how it worked except that somehow all the terminals ran into two BSDi boxes in the core room of the central library, and it had been hardened so you could not break out of the menus and telnet to arbitrary places. Over a year I replaced them all with windows machines that ran version of netscape navigator as the shell with an interface that was built in signed javascript. It was the early days of the web, and we had to support over 300 plug ins for different subscriptions we had. The department that ran the campus network didn't want to let me on the network until I could prove to them everything was secure.
    - ciceryadam 3y ago
      SSH was a replacement for RSH, not telnet.
      - hnfong 3y ago
        This was on HN two(?) days ago: https://news.ycombinator.com/item?id=39313170 https://news.ycombinator.com/item?id=39313170 > I wrote the initial version of SSH (Secure Shell) in Spring 1995. It was a time when telnet and FTP were widely used. > Anyway, I designed SSH to replace both telnet (port 23) and ftp (port 21). Port 22 was free. It was conveniently between the ports for telnet and ftp. I figured having that port number might be one of those small things that would give some aura of credibility. But how could I get that port number? I had never allocated one, but I knew somebody who had allocated a port. Emphasis mine. Cheers.
        ciceryadam 3y ago
        https://docs.oracle.com/cd/E36784_01/html/E36870/ssh-1.html https://docs.oracle.com/cd/E36784_01/html/E36870/ssh-1.html from man page: It is intended to replace rlogin and rsh, and to provide secure encrypted communications between two untrusted hosts over an insecure network.
      - quesera 3y ago
        Where does this idea come from? I see it repeated a lot, but it's not correct. rsh was common on internal networks, but almost never used on the wider Internet. telnet was everywhere all across the net. ssh was a revelation and it replaced telnet and authenticated/non-anonymous ftp primarily. And also sometimes rsh, but less importantly.
        xorcist 3y ago
        How could it be incorrect? rsh was clearly modelled after rlogin, and ssh was clearly modelled after rsh. The command line options were almost identical for an easy switch. ssh even respected the .rhosts file! Last time I checked, that functionality was still in place. Both the rlogin-family of commands and the telnet/ftp-family were in use across the Internet, certainly in cases where Kerberos was used. I would think telnet was more common, certainly so outside the UNIX sphere of influence, but things like Kermit also existed. They all got SSL-encapsulated versions in time, but Kerberos solved authentication for free, and for the simpler use cases ssh had already taken over by then. And in the longer run, simple almost always wins!
- TylerE 3y ago
  I wonder how many of these things that are just coasting are gonna have issues in 14 years.
- korhojoa 3y ago
  This already happened with the kernel console, no more scrollback. https://security.snyk.io/vuln/SNYK-UNMANAGED-TORVALDSLINUX-3005497 https://security.snyk.io/vuln/SNYK-UNMANAGED-TORVALDSLINUX-3...
  - ale42 3y ago
    I recognize it fixed a security issue, but nonetheless it's very inconvenient. I don't always have tmux at hand, especially when the system is booting in some degraded mode...
- ngetchell 3y ago
  They're open source.
szundi 3y ago
Not the web though
- ironmagma 3y ago
  Certainly the web can mostly coast indefinitely. There are webpages from decades ago that still function fine, even that use JavaScript. The web is an incredibly stable platform all things considered. In contrast, it's hard to get a program that links to a version of Zlib from 10 years ago running on a modern Linux box.
  - quickthrower2 3y ago
    The web is the calm looking duck that is paddling frantically. You want to be using SSL from the 90s, or IE vs. Netscape as your choice etc. Nostalgia aside!
  - 5- 3y ago
    this problem -- great forward compatibility of the web -- has been taken care of with application layer encryption, deceitfully called "transport layer" security (tls)
  - KronisLV 3y ago
    > Certainly the web can mostly coast indefinitely. I'm not sure about that, for anything besides static resources, given the rate at which various vulnerabilities are found at and how large automated attacks can be, unless you want an up to date WAF in front of everything to be a pre-requisite. Well, either that or using mTLS or other methods of only letting trusted parties access your resources (which I do for a lot of my homelab), but that's not the most scalable approach. Back end code does tend to rot a lot, for example, like log4shell showed. Everything was okay one moment and then BOOM, RCEs all over the place the next. I'm all for proven solutions, but I can't exactly escape needing to do everything from OS updates, to language runtime and library updates.
- colechristensen 3y ago
  HTTP 1.1 isn’t really changing is it? That and a small collection of other things are standards based and not going though changes.
the_duke 3y ago
Nginx is still evolving a lot though. Eg: http3 support was stabilized with 1.25.1 , which came out June 2023.
Gormo 3y ago
> Also this is kind of why everything is ever so slightly broken, IMHO. OTOH, things that update too often seem to be more than slightly broken on an ongoing basis, due to ill-advised design changes, new bugs and regressions, etc.
- ironmagma 3y ago
  I am thinking with things that don't update often, we just get used to the broken parts. People learned to save every five minutes in Maya since the app crashes so often, for example. Every now and then, a PuTTY session will fill the screen with "PuTTYPuTTYPuTTYPuTTYPuTTY[...]" but it's been that way for at least 20 years, so it's not that remarkable.
  - sitzkrieg 3y ago
    tangent but i havent seen that happen on any of my putty clients in years and i use it everyday, so i think that finally got fixed? or maybe was a side effect of something stupid
    - ikt 3y ago
      next question: why are people still using putty
      - doublerabbit 3y ago
        Why shouldn't people use putty? I still use putty because it does what I need for it to do. No need to change just because MS has their own terminals application, which besides I far from trust.
        mcsniff 3y ago
        You trust them to run the entire OS and every stack included in it, but not to make an ssh client?
stusmall 3y ago
This isn't one though. I think the issue he is talking about is around the CVEs that came out with the HTTP3 implementation. This is an area of very active and complex development.
whatever1 3y ago
Meanwhile my anaconda installation died after a casual apt-get update lol I now believe that every piece of software should be shipped as a container to avoid any system library dependencies.
- MightyBuzzard 3y ago
  [dead]
- ironmagma 3y ago
  That is what Snap is for, but there are… issues

yjftsjthsd-h 3y ago

That only helps if it stays static. For example, if the Linux TTY interface was unchanged for decades to such a degree that nobody worked on it, but then had a vulnerability, who would be able to fix it quickly?

ironmagma 3y ago
Perhaps someone with more knowledge can chime in. But, my impression is that there are vulnerabilities with TTY, it's just that we stay educated on what those are. And we build systems around it (e.g. SSH) that are secure enough to mitigate the effects of those issues.
- codetrotter 3y ago
  SSH was a replacement for Telnet. But any weaknesses at the TTY level is orthogonal to that, right? Unless you mean, having thin clients use SSH as opposed to directly running serial cables throughout a building to VT100 style hardware terminals, and therefore being vulnerable to eavesdropping and hijacking? But I think when we talk about TTY we mostly don’t refer to that kind of situation. If someone talks about TTY today, I assume they mean the protocol and kernel interfaces being used. Not any kind of physical VT100 style serial communication terminals.
  - tingletech 3y ago
    I miss rooms of green and amber screen terminals hooked up via serial cable. As an undergrad I remember figuring out how to escape from some menu to a TTY prompt that I could somehow telnet to anywhere from. Later, I would inherit a fleet of 200 of them spread across 12 branch libraries. I can't remember how it worked except that somehow all the terminals ran into two BSDi boxes in the core room of the central library, and it had been hardened so you could not break out of the menus and telnet to arbitrary places. Over a year I replaced them all with windows machines that ran version of netscape navigator as the shell with an interface that was built in signed javascript. It was the early days of the web, and we had to support over 300 plug ins for different subscriptions we had. The department that ran the campus network didn't want to let me on the network until I could prove to them everything was secure.
  - ciceryadam 3y ago
    SSH was a replacement for RSH, not telnet.
    - hnfong 3y ago
      This was on HN two(?) days ago: https://news.ycombinator.com/item?id=39313170 https://news.ycombinator.com/item?id=39313170 > I wrote the initial version of SSH (Secure Shell) in Spring 1995. It was a time when telnet and FTP were widely used. > Anyway, I designed SSH to replace both telnet (port 23) and ftp (port 21). Port 22 was free. It was conveniently between the ports for telnet and ftp. I figured having that port number might be one of those small things that would give some aura of credibility. But how could I get that port number? I had never allocated one, but I knew somebody who had allocated a port. Emphasis mine. Cheers.
      - ciceryadam 3y ago
        https://docs.oracle.com/cd/E36784_01/html/E36870/ssh-1.html https://docs.oracle.com/cd/E36784_01/html/E36870/ssh-1.html from man page: It is intended to replace rlogin and rsh, and to provide secure encrypted communications between two untrusted hosts over an insecure network.
    - quesera 3y ago
      Where does this idea come from? I see it repeated a lot, but it's not correct. rsh was common on internal networks, but almost never used on the wider Internet. telnet was everywhere all across the net. ssh was a revelation and it replaced telnet and authenticated/non-anonymous ftp primarily. And also sometimes rsh, but less importantly.
      - xorcist 3y ago
        How could it be incorrect? rsh was clearly modelled after rlogin, and ssh was clearly modelled after rsh. The command line options were almost identical for an easy switch. ssh even respected the .rhosts file! Last time I checked, that functionality was still in place. Both the rlogin-family of commands and the telnet/ftp-family were in use across the Internet, certainly in cases where Kerberos was used. I would think telnet was more common, certainly so outside the UNIX sphere of influence, but things like Kermit also existed. They all got SSL-encapsulated versions in time, but Kerberos solved authentication for free, and for the simpler use cases ssh had already taken over by then. And in the longer run, simple almost always wins!
TylerE 3y ago
I wonder how many of these things that are just coasting are gonna have issues in 14 years.
korhojoa 3y ago
This already happened with the kernel console, no more scrollback. https://security.snyk.io/vuln/SNYK-UNMANAGED-TORVALDSLINUX-3005497 https://security.snyk.io/vuln/SNYK-UNMANAGED-TORVALDSLINUX-3...
- ale42 3y ago
  I recognize it fixed a security issue, but nonetheless it's very inconvenient. I don't always have tmux at hand, especially when the system is booting in some degraded mode...
ngetchell 3y ago
They're open source.

szundi 3y ago

Not the web though

ironmagma 3y ago
Certainly the web can mostly coast indefinitely. There are webpages from decades ago that still function fine, even that use JavaScript. The web is an incredibly stable platform all things considered. In contrast, it's hard to get a program that links to a version of Zlib from 10 years ago running on a modern Linux box.
- quickthrower2 3y ago
  The web is the calm looking duck that is paddling frantically. You want to be using SSL from the 90s, or IE vs. Netscape as your choice etc. Nostalgia aside!
- 5- 3y ago
  this problem -- great forward compatibility of the web -- has been taken care of with application layer encryption, deceitfully called "transport layer" security (tls)
- KronisLV 3y ago
  > Certainly the web can mostly coast indefinitely. I'm not sure about that, for anything besides static resources, given the rate at which various vulnerabilities are found at and how large automated attacks can be, unless you want an up to date WAF in front of everything to be a pre-requisite. Well, either that or using mTLS or other methods of only letting trusted parties access your resources (which I do for a lot of my homelab), but that's not the most scalable approach. Back end code does tend to rot a lot, for example, like log4shell showed. Everything was okay one moment and then BOOM, RCEs all over the place the next. I'm all for proven solutions, but I can't exactly escape needing to do everything from OS updates, to language runtime and library updates.
colechristensen 3y ago
HTTP 1.1 isn’t really changing is it? That and a small collection of other things are standards based and not going though changes.

the_duke 3y ago

Nginx is still evolving a lot though. Eg: http3 support was stabilized with 1.25.1 , which came out June 2023.

Gormo 3y ago

> Also this is kind of why everything is ever so slightly broken, IMHO. OTOH, things that update too often seem to be more than slightly broken on an ongoing basis, due to ill-advised design changes, new bugs and regressions, etc.

ironmagma 3y ago
I am thinking with things that don't update often, we just get used to the broken parts. People learned to save every five minutes in Maya since the app crashes so often, for example. Every now and then, a PuTTY session will fill the screen with "PuTTYPuTTYPuTTYPuTTYPuTTY[...]" but it's been that way for at least 20 years, so it's not that remarkable.
- sitzkrieg 3y ago
  tangent but i havent seen that happen on any of my putty clients in years and i use it everyday, so i think that finally got fixed? or maybe was a side effect of something stupid
  - ikt 3y ago
    next question: why are people still using putty
    - doublerabbit 3y ago
      Why shouldn't people use putty? I still use putty because it does what I need for it to do. No need to change just because MS has their own terminals application, which besides I far from trust.
      - mcsniff 3y ago
        You trust them to run the entire OS and every stack included in it, but not to make an ssh client?

stusmall 3y ago

This isn't one though. I think the issue he is talking about is around the CVEs that came out with the HTTP3 implementation. This is an area of very active and complex development.

whatever1 3y ago

Meanwhile my anaconda installation died after a casual apt-get update lol I now believe that every piece of software should be shipped as a container to avoid any system library dependencies.

MightyBuzzard 3y ago
[dead]
ironmagma 3y ago
That is what Snap is for, but there are… issues