Using the `net` server type - TLS not working at all

I tried using caddy-net by @pieterlouw as TLS proxy for my personal mail server to handle SMTP/IMAP via TLS but couldn’t get it working, so I tried getting a minimal setup working first but even failed there.

I followed the blogpost which is also referenced in caddy-net's README:

proxy :2000 127.0.0.1:1338 {
    host host.mydomain.tld
    tls self_signed
}

I also started the minimal tcpserver example which works just as expected when “talking” to it locally via telnet localhost 1338 or using tls off and telnet host.mydomain.tld 2000.

It seems setting tls self_signed or tls my@mailaddress has no effect at all, as openssl s_client -connect localhost:2000 shows that the raw TLS packets are simply passed through to the tcpserver backend which then expectedly gets confused:

Client:

$ openssl s_client -connect localhost:2000
CONNECTED(00000003)
140026879686360:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:797:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 308 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID: 
    Session-ID-ctx: 
    Master-Key: 
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1506590473
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

Server:

$ tcpserver 127.0.0.1 1338 ${PWD}/server.py
Traceback (most recent call last):
  File "/home/elias/tmp/caddy-net/server.py", line 4, in <module>
    user = input("> ")
  File "/usr/lib/python-exec/python3.4/../../../lib64/python3.4/codecs.py", line 319, in decode
    (result, consumed) = self._buffer_decode(data, self.errors, final)
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe3 in position 11: invalid continuation byte

What’s weird about Caddy’s startup is its claim there’d be already a certificate loaded, which it definitely isn’t.:

$ CADDYPATH=${PWD} ./caddy -log=stdout -agree=true -root=${PWD} -type=net -conf=Caddyfile
2017/09/28 11:33:48 [NOTICE] There is already a certificate loaded for , so certificate for [ ] will not service that name
2017/09/28 11:33:48 [NOTICE] There is already a certificate loaded for , so certificate for [] will not service that name
2017/09/28 11:33:48 [NOTICE] There is already a certificate loaded for , so certificate for [] will not service that name
Activating privacy features... done.
[INFO] Proxying from  :2000  ->  127.0.0.1:1338

Could it be that this is caused by the changes introduced in #1821 and how caddy-net handles TLS? Does it need to be adapted to chose changes?

Used versions:

  • Caddy 0.10.9
  • net server type plugin 0.1.1

Hi @eliasp,

Thanks for the great problem report.
This looks very tls specific and would need to reproduce this from my end. The net server type leverages the Caddy tls directive, there’s not much control I have over tls from the plugin’s perspective, unless the problem exists with the plugin passing wrong info the the tls directive.

@matt , have you come across anything like this ?

@pieterlouw The caddytls package doesn’t allow certificates keyed by a certain host name to overwrite certificates keyed by the same name that are already in the cache. It seems to be, in this case, that the certificate that’s being loaded has an empty name value in its Names field. The space in the two messages between [ ] and [] is only significant in that the first certificate to be loaded has a Name of "" appended to it to be the default certificate; but [] shows that more certificates are being cached with an empty name value (since Caddy only appends "" name to the first cert that is loaded).

1 Like

I am having a similar issue tho my logs are like

Activating privacy features... done.
[INFO] Proxying from  :8081  ->  rtmp:8080
Done proxying: 172.18.0.10:8081 10.0.0.196:50896

and i am using the dns provider cloud flare with all the appropriate env vars

when connecting with openssl i get the same result
its as if its not serving the tls connection at all

CONNECTED(00000003)
140001557903264:error:140770FC:SSL routines:SSL23_GET_SERVER_HELLO:unknown protocol:s23_clnt.c:794:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 289 bytes
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : 0000
    Session-ID:
    Session-ID-ctx:
    Master-Key:
    Key-Arg   : None
    Krb5 Principal: None
    PSK identity: None
    PSK identity hint: None
    Start Time: 1514393375
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
---

my config is

proxy :8081 rtmp:8080 {
host FQDN.NAME
  tls MY@EMAIL.ADDR {
    dns cloudflare
  }
}

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.