Friday, February 25, 2022

Debugging Network Communications - For the Rest of the World


In one of my very early forays into IHE standards implementation, I had to implement TLS version 1.0 shortly after it became an IETF RFC, in Java, using Tomcat.  Thus began the ATNA FAQ.  Thiat document is now 15 years old, and is still being used (at least by me).  I started writing these kinds of things down so I don't forget them, which eventually resulted in this blog.

I'm still debugging TLS connections, and I have to admit that it's become a particular art form, but not so much as in finding out what when wrong, and figuring out the solution, but rather in explaining it to someone who is NOT versed in the ingredients of TLS connection sausages so that can a) find the right person to fix it, and b) communicate what needs to be fixed without c) further intervention from me.  That's high art.

I have a highly evolved tool set including:

  • DNS, Ping and TraceRt
  • WireShark
  • OpenSsl
  • JVM debugging arguments
Here's the problems these tools help me identify.  Each requires appropriate communication..
  1. My computer cannot get a good TCP/IP address for the supplied hostname.
    1. Either DNS is down somewhere, or the new DNS record is still propagating, or it simply does not exist.
  2. My computer cannot connect to the TCP/IP address that DNS gave it.
    1. The DNS change for your server may still be propagating
    2. That IP address is not connected to the Internet, is not within my reachable networks
      1. The sending computer sends a SYN, but no ACK is ever returned.
        1. Ping returns no response to that IP (may be blocked by a firewall).
    3. The firewall doesn't like the computer it is coming from.
      1. Same symptoms as above.  Firewalls and application gateways (Firewalls on steroids) and other interfacing technologies (e.g., AWS Lambdas or Azure Functions, gateways that have been weaned from Steroids) can mimic just about anything, but most often, they just hide your computer from mine.
    4. The computer is actively NOT listening to connections from that address.
      1. SYN goes out, but a RST comes back.  In other words, I'm listening to communications, just not to THAT port.
  3. The computers can connect (three way TCP SYN, ACK, SYN-ACK completed), but we cannot make a TLS connection.
    1. My client sent your computer a TLS version it didn't like. You server needs to enable support for TLS Version (1.2 or higher).
    2. My client sent your computer a set of encryption protocols it really doesn't care for.  Your server needs to enable the following encryption protocols ...  (RSA or DCHE Galois Cipher Mode[GCM]).  Cyclic block cyphers (CBC) are no longer considered to be secure.
    3. Your server sent my system a certificate it didn't like, it was:
      1. Expired, please renew it
      2. Revoked,  please replace it with a new certificate
      3. Not secure enough ... please use a certificate supporting at cipher strength of at least (2048 bits).
      4. Not signed by an entity trusted on my end
        1. Our system doesn't accept self-signed certificates, please get your certificate signed by (a commonly trusted CA, or a CA of my choosing)
      5. Prepared using an algorithm my server doesn't support.  Please use an certificate signed using (the RSA algorithm).
      6. For a server going by a different name (this one is rare.  Hostname matching is important in many circumstances, but in cases where the server that is supplying the certificate is three layers deep behind other network infrastructure, it has no clue, and so is often disabled.
    4. Your server required a client certificate from my system that it doesn't have.
      1. Here's our certificate chain, please trust someone in this chain - OR -
      2. Please supply me with the necessary client certificate and the instructions for the obtaining one (the administrative hoops that I have to jump through to get them).
The problem with this are:
  1. The tools are complicated and require either good training or documentation for folks who haven't needed to learn to use them.
  2. You actually have to understand how the Internet standards work to determine what tool to use and when.
  3. I don't scale.  We need me in a box (or more specifically, in a service).
So, I've resolved to work on a tool to do this sort of testing for me, with the details about what is wrong written in very user friendly language about what it finds about the problem.  It's an interesting bit of interface engineering.



0 comments:

Post a Comment