8 ms·

I feel for later generations - learning tech gets harder and harder. Of course as the sum of knowledge increases this must be true, but as we go HTTPS-only the

I feel for later generations - learning tech gets harder and harder. Of course as the sum of knowledge increases this must be true, but as we go HTTPS-only the ability to type commands to a web server over telnet as a learning experience will be a loss.

besselheim 10y ago
You could type them over openssl s_client instead.
- pimlottc 10y ago
  Indeed, the openssl tool is a veritable swiss army knife for PKI crypto. It's a netcat replacement: openssl s_client -connect www.google.com:443 while also providing information on the TLS handshake that's useful for debugging (like the server's certificate chain or its list of trusted CAs for client certificates). There's dozens of other subcommands to do useful things like decode certificates (x509), generate keys (genrsa/gendsa) and create certificate signing requests (req), just to name a few.
  - syncsynchalt 10y ago
    It's not a great netcat replacement, for one it's not binary transparent (eg. a SMTP "RCPT TO" causes a rekey due to the pattern "\nR.*\n"). The command line usage is atrocious too. That said there are many good alternatives (ncat, telnet-ssl, etc), and eventually one will gain the popularity and ubiquity that nc, curl, and similar tools did before them.
- majewsky 10y ago
  openssl s_client is really valuable if you regularly work with minimal container images that don't have curl, wget or even ncat. openssl(1) is almost always there.
ratchetratchet 10y ago
I got you bro! $:openssl s_client -connect localhost:443 CONNECTED(00000003) ...snip.... lots of cert info ...snip... GET / HTTP/1.0
userbinator 10y ago
...as is the ability to inspect the traffic in your network to and from the devices you own. I think that is an even scarier situation, considering what others have discovered about "smart" devices precisely because their traffic was not encrypted. E.g. https://news.ycombinator.com/item?id=6759426 https://news.ycombinator.com/item?id=6759426 Personally, I'm for HTTPS connections to things like government websites (which is what this article seems to be mostly about), but against "HTTPS everything" in the way it's going to be implemented.
- ycmbntrthrwaway 10y ago
  If you want to avoid telemetry, you need to use open source devices. Prohibiting HTTPS for everything non-government is not a way to go.
- test235 10y ago
  > but against "HTTPS everything" You being against HTTPS everything, is the same as being in support of MITM attacks somewhere. I am curious when is that the allowable case?
  - userbinator 10y ago
    I own my computing devices and I should be able to control the traffic they create. Encryption must not prevent me from doing that.
    - rhaps0dy 10y ago
      Since you own the computing device and the connection, it's theoretically possible to read the session encryption keys from its memory. This may be really hard in practice though.
    - dschep 10y ago
      And you still can MITM the traffic, you just have to install your MITM's cert on your device you want to MITM.
LeanderK 10y ago
i think that's more a tooling problem. Making tech accessible to someone new really important.
dTal 10y ago
Learning a field should get easier the more we collectively know about it - the information should be structured better. This is particularly true of software, where we decide how to structure it. If tech is getting harder, this is our failing, not an inevitability.
- pjc50 10y ago
  Other way round: the more structure we build, the more there is to learn. The blank-slate nature of software is particularly problematic here; people end up proliferating solutions faster than they can be learned.
spydum 10y ago
As others have pointed out, there are tools for creating a TLS socket, not much harder than nc or telnet. However, HTTP/2 will be a totally different game.
- marios 10y ago
  FWIW, OpenBSD's netcat supports creating a TLS socket. I'm not sure it will work on all Linux distributions since it depends on libtls/LibreSSL and most ship with OpenSSL.
- ycmbntrthrwaway 10y ago
  Even with HTTP you usually don't use netcat beyond playing with simple GET requests. Most web app developers and hackers use developer tools available in their browser, libraries for their favourite language (urllib for Python, LWP for Perl) and specialized command-line tools (curl).
  - spydum 10y ago
    fully agree, but I think the point was around the educational value of literally being able to handcraft HTTP requests. I learned a ton back in the 90's doing exactly that for various plaintext protocols (FTP, SMTP, POP3, IMAP, HTTP). Yes, there are tools that let you inspect them, but there's something about being able to walk around right at the protocol level to understand it's nuances (e.g.: CR/LF issues with HTTP). However, all of that being said, I'm sure the real old-school hackers think all this PHP/Python/Perl mumbo jumbo obscures the real C/C++ code which their interpreters actually drive. And those old-old-school hackers think those C/C++ guys are obscuring their assembly code.. okay, I kid, but you get the point. We all deal with abstractions at some point. Perhaps in time, HTTP/2 tooling will come to improve, and my concerns will vanish as well.
omegaham 10y ago
You might have to do some custom work to make some of the "history" accessible. For example, Stanford's CS144 class uses a patched version of the Linux kernel to enable people to create their own TCP/IP clients[1]. I'm sure that if stuff like this becomes really inaccessible for newbies, similar modifications will be done for other applications to allow simpler concepts to be taught and explored. [1] http://web.stanford.edu/class/cs144/assignments/ctcp/assignment.html http://web.stanford.edu/class/cs144/assignments/ctcp/assignm...
ycmbntrthrwaway 10y ago
Telnet/netcat seems simple only because all the layers below are hidden inside the operating system. You don't type in all the MAC/LLC/TCP headers, and you can avoid typing in TLS headers just by hiding them inside the library (LibreSSL, GnuTLS etc.). With libtls API you can think about cryptography in terms of "padlock icon" until you want to learn more.
- timthorn 10y ago
  No, but you can build your own stack from scratch fairly easily, and it's easier to debug when you can see the plaintext through the data structures.
  - tetrep 10y ago
    And it's easier to debug a video codec if it's ASCII art, but there's huge benefits for using TLS everywhere instead of plaintext, and they more than outweigh "it's harder to debug."
- paulddraper 10y ago
  True, though reimplementing those is child's play compared to TLS.
  - tptacek 10y ago
    Having done semi-serious implementations of both, I disagree. Implementing IP and TCP and getting it hooked up to your OS so that your packets get spat out the network card and your responses get relayed back to your code is much harder than implementing a minimal TLS.
    - ycmbntrthrwaway 10y ago
      True. Minimal TCP with 1 MSS window may be easy, but proper congestion control with fast recovery, F-RTO, tail loss probe, SACK etc. is much harder. Miss one of these aspects and you get a TCP that takes minutes to recover from a lost packet in some obscure case. It took years to debug Linux TCP stack. Even BSD stack is already way behind.
Klathmon 10y ago
That's how progress works. 50 years ago you could work on a brand new car with just the tools in your garage, now you'd need specialized knowledge, equipment, and more to the point that it's not really possible to be a home mechanic on many areas. This isn't new for new's sake, these improvements bring real benefits. And as things get more complex, people will specialize more and more. In the future, your average "dev" might not know the ins and outs of how the transport layer works, but that's okay because there is someone else who mainly only does that.
- pythonlion 10y ago
  you can build a brand new 1967 car with just the tools in your garage? Wow
  - chucky_z 10y ago
    I mean... yeah, actually, you can -- if you had every (new) part from, say, a 1967 Ford F-series truck, anyone could absolutely, with just a Chiltons and a good set of tools, put together every nut, bolt, and screw from a giant crate of parts to build it.
    - pythonlion 10y ago
      That's interesting. I wish I could buy these "kits" today, put it together myself and drive a cheap cool car. Is that was a option then?
      - stan_rogers 10y ago
        It wouldn't be cheap. The safest, cheapest and most efficient "packing crate" for the parts for a single car is the assembled vehicle. (It's somewhat different when you can stack 50 left front fenders.) A kit car (most use fibreglass bodies) would be a much better option. Expect to spend about 1000 hours (much of that building jigs). The second one you build goes much smoother and faster than the first, even if it's a different kit based on a completely different pair of vehicles (the "source", from which most of the drive train parts will be drawn, and "target").
tptacek 10y ago
This objection has always seemed pretty weird to me. Of course you can type HTTP commands character-by-character into a terminal. You just have to use a TLS-aware tool to do it. Meanwhile, you can't really just type HTTP commands to a server without tooling, because a whole bunch of TCP is happening behind the scenes. Why is "telnet" OK, but OpenSSL "s_client" isn't?
- tedunangst 10y ago
  You can't type any lines beginning with Q or R with s_client.
  - besselheim 10y ago
    You can use the -quiet or -ign_eof options to disable this.
    - icebraining 10y ago
      You can also use socat (the multipurpose relay) to provide a bare TCP socket to which you can connect, even using telnet.
  - mattstreet 10y ago
    Then it should also be noted that you really shouldn't use telnet to interact with HTTP or SMTP either. Telnet has issues if you send control characters, which wouldn't be used for either protocol, but might exist in embedded data you might want to send or receive. Just use netcat.
    - tptacek 10y ago
      I guess, but it's hard to think of an HTTP request you can't reasonably make with telnet, while s_client apparently won't let you use the Referer header.
discreditable 10y ago
> the ability to type commands to a web server over telnet as a learning experience will be a loss. You can do this with openssl. openssl s_client -connect news.ycombinator.com:443 GET / HTTP/1.1 Host: news.ycombinator.com Press enter twice and you'll get HTML.
- cxseven 10y ago
  There's also "socat", which is netcat with ssl support and it carries over its friendly command line.
- deleted 10y ago
  [deleted]
  - deleted 10y ago
    [deleted]
  - deleted 10y ago
    [deleted]
wmil 10y ago
The bigger issue is hardware / software that manufacturers won't update. HTTPS best practices often require servers to drop support for old protocols. So if you pull out a 10 year old palm pilot and try to go to HN it won't work due to SSL.
- timthorn 10y ago
  Indeed, computer history museums are going to only be able to show older working exhibits - cloud backed gadgets will just be objects to look at and imagine what they used to be.
meddlepal 10y ago
Job security.

besselheim 10y ago

You could type them over openssl s_client instead.

pimlottc 10y ago
Indeed, the openssl tool is a veritable swiss army knife for PKI crypto. It's a netcat replacement: openssl s_client -connect www.google.com:443 while also providing information on the TLS handshake that's useful for debugging (like the server's certificate chain or its list of trusted CAs for client certificates). There's dozens of other subcommands to do useful things like decode certificates (x509), generate keys (genrsa/gendsa) and create certificate signing requests (req), just to name a few.
- syncsynchalt 10y ago
  It's not a great netcat replacement, for one it's not binary transparent (eg. a SMTP "RCPT TO" causes a rekey due to the pattern "\nR.*\n"). The command line usage is atrocious too. That said there are many good alternatives (ncat, telnet-ssl, etc), and eventually one will gain the popularity and ubiquity that nc, curl, and similar tools did before them.
majewsky 10y ago
openssl s_client is really valuable if you regularly work with minimal container images that don't have curl, wget or even ncat. openssl(1) is almost always there.

ratchetratchet 10y ago

I got you bro! $:openssl s_client -connect localhost:443 CONNECTED(00000003) ...snip.... lots of cert info ...snip... GET / HTTP/1.0

userbinator 10y ago

...as is the ability to inspect the traffic in your network to and from the devices you own. I think that is an even scarier situation, considering what others have discovered about "smart" devices precisely because their traffic was not encrypted. E.g. https://news.ycombinator.com/item?id=6759426 https://news.ycombinator.com/item?id=6759426 Personally, I'm for HTTPS connections to things like government websites (which is what this article seems to be mostly about), but against "HTTPS everything" in the way it's going to be implemented.

ycmbntrthrwaway 10y ago
If you want to avoid telemetry, you need to use open source devices. Prohibiting HTTPS for everything non-government is not a way to go.
test235 10y ago
> but against "HTTPS everything" You being against HTTPS everything, is the same as being in support of MITM attacks somewhere. I am curious when is that the allowable case?
- userbinator 10y ago
  I own my computing devices and I should be able to control the traffic they create. Encryption must not prevent me from doing that.
  - rhaps0dy 10y ago
    Since you own the computing device and the connection, it's theoretically possible to read the session encryption keys from its memory. This may be really hard in practice though.
  - dschep 10y ago
    And you still can MITM the traffic, you just have to install your MITM's cert on your device you want to MITM.

LeanderK 10y ago

i think that's more a tooling problem. Making tech accessible to someone new really important.

dTal 10y ago

Learning a field should get easier the more we collectively know about it - the information should be structured better. This is particularly true of software, where we decide how to structure it. If tech is getting harder, this is our failing, not an inevitability.

pjc50 10y ago
Other way round: the more structure we build, the more there is to learn. The blank-slate nature of software is particularly problematic here; people end up proliferating solutions faster than they can be learned.

spydum 10y ago

As others have pointed out, there are tools for creating a TLS socket, not much harder than nc or telnet. However, HTTP/2 will be a totally different game.

marios 10y ago
FWIW, OpenBSD's netcat supports creating a TLS socket. I'm not sure it will work on all Linux distributions since it depends on libtls/LibreSSL and most ship with OpenSSL.
ycmbntrthrwaway 10y ago
Even with HTTP you usually don't use netcat beyond playing with simple GET requests. Most web app developers and hackers use developer tools available in their browser, libraries for their favourite language (urllib for Python, LWP for Perl) and specialized command-line tools (curl).
- spydum 10y ago
  fully agree, but I think the point was around the educational value of literally being able to handcraft HTTP requests. I learned a ton back in the 90's doing exactly that for various plaintext protocols (FTP, SMTP, POP3, IMAP, HTTP). Yes, there are tools that let you inspect them, but there's something about being able to walk around right at the protocol level to understand it's nuances (e.g.: CR/LF issues with HTTP). However, all of that being said, I'm sure the real old-school hackers think all this PHP/Python/Perl mumbo jumbo obscures the real C/C++ code which their interpreters actually drive. And those old-old-school hackers think those C/C++ guys are obscuring their assembly code.. okay, I kid, but you get the point. We all deal with abstractions at some point. Perhaps in time, HTTP/2 tooling will come to improve, and my concerns will vanish as well.

omegaham 10y ago

You might have to do some custom work to make some of the "history" accessible. For example, Stanford's CS144 class uses a patched version of the Linux kernel to enable people to create their own TCP/IP clients[1]. I'm sure that if stuff like this becomes really inaccessible for newbies, similar modifications will be done for other applications to allow simpler concepts to be taught and explored. [1] http://web.stanford.edu/class/cs144/assignments/ctcp/assignment.html http://web.stanford.edu/class/cs144/assignments/ctcp/assignm...

ycmbntrthrwaway 10y ago

Telnet/netcat seems simple only because all the layers below are hidden inside the operating system. You don't type in all the MAC/LLC/TCP headers, and you can avoid typing in TLS headers just by hiding them inside the library (LibreSSL, GnuTLS etc.). With libtls API you can think about cryptography in terms of "padlock icon" until you want to learn more.

timthorn 10y ago
No, but you can build your own stack from scratch fairly easily, and it's easier to debug when you can see the plaintext through the data structures.
- tetrep 10y ago
  And it's easier to debug a video codec if it's ASCII art, but there's huge benefits for using TLS everywhere instead of plaintext, and they more than outweigh "it's harder to debug."
paulddraper 10y ago
True, though reimplementing those is child's play compared to TLS.
- tptacek 10y ago
  Having done semi-serious implementations of both, I disagree. Implementing IP and TCP and getting it hooked up to your OS so that your packets get spat out the network card and your responses get relayed back to your code is much harder than implementing a minimal TLS.
  - ycmbntrthrwaway 10y ago
    True. Minimal TCP with 1 MSS window may be easy, but proper congestion control with fast recovery, F-RTO, tail loss probe, SACK etc. is much harder. Miss one of these aspects and you get a TCP that takes minutes to recover from a lost packet in some obscure case. It took years to debug Linux TCP stack. Even BSD stack is already way behind.

Klathmon 10y ago

That's how progress works. 50 years ago you could work on a brand new car with just the tools in your garage, now you'd need specialized knowledge, equipment, and more to the point that it's not really possible to be a home mechanic on many areas. This isn't new for new's sake, these improvements bring real benefits. And as things get more complex, people will specialize more and more. In the future, your average "dev" might not know the ins and outs of how the transport layer works, but that's okay because there is someone else who mainly only does that.

pythonlion 10y ago
you can build a brand new 1967 car with just the tools in your garage? Wow
- chucky_z 10y ago
  I mean... yeah, actually, you can -- if you had every (new) part from, say, a 1967 Ford F-series truck, anyone could absolutely, with just a Chiltons and a good set of tools, put together every nut, bolt, and screw from a giant crate of parts to build it.
  - pythonlion 10y ago
    That's interesting. I wish I could buy these "kits" today, put it together myself and drive a cheap cool car. Is that was a option then?
    - stan_rogers 10y ago
      It wouldn't be cheap. The safest, cheapest and most efficient "packing crate" for the parts for a single car is the assembled vehicle. (It's somewhat different when you can stack 50 left front fenders.) A kit car (most use fibreglass bodies) would be a much better option. Expect to spend about 1000 hours (much of that building jigs). The second one you build goes much smoother and faster than the first, even if it's a different kit based on a completely different pair of vehicles (the "source", from which most of the drive train parts will be drawn, and "target").

tptacek 10y ago

This objection has always seemed pretty weird to me. Of course you can type HTTP commands character-by-character into a terminal. You just have to use a TLS-aware tool to do it. Meanwhile, you can't really just type HTTP commands to a server without tooling, because a whole bunch of TCP is happening behind the scenes. Why is "telnet" OK, but OpenSSL "s_client" isn't?

tedunangst 10y ago
You can't type any lines beginning with Q or R with s_client.
- besselheim 10y ago
  You can use the -quiet or -ign_eof options to disable this.
  - icebraining 10y ago
    You can also use socat (the multipurpose relay) to provide a bare TCP socket to which you can connect, even using telnet.
- mattstreet 10y ago
  Then it should also be noted that you really shouldn't use telnet to interact with HTTP or SMTP either. Telnet has issues if you send control characters, which wouldn't be used for either protocol, but might exist in embedded data you might want to send or receive. Just use netcat.
  - tptacek 10y ago
    I guess, but it's hard to think of an HTTP request you can't reasonably make with telnet, while s_client apparently won't let you use the Referer header.

discreditable 10y ago

> the ability to type commands to a web server over telnet as a learning experience will be a loss. You can do this with openssl. openssl s_client -connect news.ycombinator.com:443 GET / HTTP/1.1 Host: news.ycombinator.com Press enter twice and you'll get HTML.

cxseven 10y ago
There's also "socat", which is netcat with ssl support and it carries over its friendly command line.
deleted 10y ago
[deleted]
- deleted 10y ago
  [deleted]
- deleted 10y ago
  [deleted]

wmil 10y ago

The bigger issue is hardware / software that manufacturers won't update. HTTPS best practices often require servers to drop support for old protocols. So if you pull out a 10 year old palm pilot and try to go to HN it won't work due to SSL.

timthorn 10y ago
Indeed, computer history museums are going to only be able to show older working exhibits - cloud backed gadgets will just be objects to look at and imagine what they used to be.

meddlepal 10y ago

Job security.