SSL/TLS Issues

Tools

Curl

Curl can analylse the TLS connection and prodive some indication of issues.

# curl -k -nn -vvv https://path.to.roadrunner:<port> 

Openssl

The OpenSSL client can be use to run an indepth analysis of a TLS connection.

openssl s_client -msg -debug -security_debug_verbose -connect <path.to.roadrunner:<port>

TLS Handshake Error

References:
Walkthrough of a TLS Handshake

Things to Check:

• Check that system time on server and client are correct. NTP is recommended.
• Check that no man-in-the-middle like proxies, and gateways.
• Check that TLS/SSL is not blocked by firewall.
• Use Curl to check and debug TLS connection.
• Use openssl to debug handshake

TLS Timeout Error

If the connection appears to be connected, but noting is happening and eventually get this message: "Connection error: Timed out waiting SSL".

024-07-12T20:44:16.957300+00:00    info       management          Connecting to management server: 10.48.168.169:55777; Attempt: 1
2024-07-12T20:44:23.216462+00:00    info       agentHealth         Starting CPU monitoring thread
2024-07-12T20:44:31.959772+00:00    error      management          Connection error: Timed out waiting SSL
2024-07-12T20:44:38.405440+00:00    info       management          Connecting to management server: 10.48.168.169:55777; Attempt: 2
2024-07-12T20:44:53.407889+00:00    error      management          Connection error: Timed out waiting SSL

This can occur on a non typical setup when one of the interfaces has an MTU less than the Docker network interface. To verify this on the host run the "ip link" command:

1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:15:ad:01:01:01 brd ff:ff:ff:ff:ff:ff
3: vpn1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1400 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 00:aa:bb:cc:01:01 brd ff:ff:ff:ff:ff:ff
4: docker0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP mode DEFAULT group default
    link/ether 02:42:04:c0:2e:73 brd ff:ff:ff:ff:ff:ff
5: veth89f7d43@if4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master docker0 state UP mode DEFAULT group default
    link/ether de:6b:26:13:52:32 brd ff:ff:ff:ff:ff:ff link-netnsid 0

In this example if Roadrunner is accessible via "vpn1" interface that the MTU is 1400. However, the virtual interfaces are docker0 have an MTU of 1500.

To resolve this issue requires creating a new virtual network with an MTU of the size of the smallest MTU and attaching it to the agent.

Here is an example for "docker compose":

version: '3.8'
services:
  sensor-throughput:
    container_name: "Throughput_Montreal_Ottawa"
    image: "agent-throughput-docker:r23.11"
    environment:
      AGENT_MANAGEMENT_PROXY: 192.168.1.1
    networks:
       -agentthroughputnet
    logging:
      driver: "json-file"
      options: 
        max-size: "10m"
        max-file: "3"
    volumes:
      - type: bind
        propagation: rslave
        source: ./secrets.yaml
        target: /run/secrets/secrets.yaml
networks:
  agentthroughputnet:
    driver: bridge
    driver_opts:
      com.docker.network.driver.mtu: 1400        

The option "com.docker.network.driver.mtu" will create the network interface with the proper MTU