pieterlouw / caddy-net Goto Github PK

Hi Pieter! Just wanted to let you know that an upcoming change in Caddy will affect this server type plugin. I'm opening this issue to track the progress of this plugin's alignment with the change I'll be pushing to a branch in Caddy soon. (Once Caddy's next version is released with the change, if this repo is not also updated and released after that, builds will fail on the website.)

I'll try to submit a pull request with my suggested changes, for your review, so you won't have to do too much work for it. Maybe in a week or less.

It's not a major change, but a slightly annoying one. It fixes caddyserver/caddy#1994 and caddyserver/caddy#1991.

High-level summary:

• TLS certificates have been stored in a global certificate cache, from which they are given to clients when making TLS connections. When a certificate is loaded into memory, it is keyed in this cache by the names on it.

• When a certificate is loaded with a name that overlaps another certificate, only one certificate (the first one) continues to serve that name, even though two different site definitions may load the certificates separately. In other words, there was a global name->certificate lookup even though it should be scoped per-site.

• When a Caddy instance is reloaded for an updated config (think SIGUSR1), there was nothing to erase the old certificate cache, leading to inefficiency if many sites get removed or replaced by different ones.

• The change I'm making will scope certificate cache to the *caddy.Instance instead of having one global one. Additionally, each *caddytls.Config will have its own name->certificate map so that they won't step on the toes of maps for other configs.

• This requires that the *caddy.Instance be accessible to plugins, that the Instance have some sort of storage (hint: it's a map[interface{}]interface{} but oh well), and that the caddytls.Config always be created in a way that it has a pointer to the certificate cache in the Instance's storage.

What this means for you is that simply creating a caddytls.Config by &caddytls.Config{...} is going to be replaced by a constructor that requires an Instance, caddytls.NewConfig(instance), and then you'll have to set any fields after that. It also means your NewContext() function must now takes an argument: NewContext(*Instance) (the interface has changed).

It seems like a lot, but the changes should be minimal (just a few lines perhaps) and I think for the better, but I still welcome your feedback.

... I know this is inconvenient, sorry about that. As Caddy continues to mature, these changes will become less and less frequent.

With the caddyfile:

proxy :6697 google.com:80 {
  host znc.rx14.co.uk
  tls self_signed
}

Using the v0.10.6 binary:

Activating privacy features... done.
[INFO] Proxying from  :6697  ->  google.com:80
Done proxying: 172.18.0.2:6697 172.18.0.2:40078

$ openssl s_client -host localhost -port 6697 < /dev/null
CONNECTED(00000005)
depth=0 O = Caddy Self-Signed
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 O = Caddy Self-Signed
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/O=Caddy Self-Signed
   i:/O=Caddy Self-Signed
---
Server certificate
-----BEGIN CERTIFICATE-----
MIIBajCCARGgAwIBAgIRAL8EUXZpkCkAw29YRtduN0swCgYIKoZIzj0EAwIwHDEa
MBgGA1UEChMRQ2FkZHkgU2VsZi1TaWduZWQwHhcNMTgwMjA1MjMxOTQzWhcNMTgw
MjEyMjMxOTQzWjAcMRowGAYDVQQKExFDYWRkeSBTZWxmLVNpZ25lZDBZMBMGByqG
SM49AgEGCCqGSM49AwEHA0IABEaDr6IJ1EJrW05ZzdeNA1DAhcyfMGB/xcEq9Ay+
4uUthLtTGGiRWzL3JqlS4obnyHSurBWy+yD3ToshRZP2jLejNDAyMA4GA1UdDwEB
/wQEAwIFoDATBgNVHSUEDDAKBggrBgEFBQcDATALBgNVHREEBDACggAwCgYIKoZI
zj0EAwIDRwAwRAIgc8Wh/+Cq57W/2B0kuHTMtvTQKAQ0hMaPhu93zyacW0sCIAQ9
6VllSBsQv1dCVVl20o7hHt4of/NVmX59k/6RNtaW
-----END CERTIFICATE-----
subject=/O=Caddy Self-Signed
issuer=/O=Caddy Self-Signed
---
No client certificate CA names sent
Peer signing digest: SHA384
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 753 bytes and written 269 bytes
Verification error: unable to verify the first certificate
---
New, TLSv1.2, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384
Server public key is 256 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
SSL-Session:
    Protocol  : TLSv1.2
    Cipher    : ECDHE-ECDSA-AES256-GCM-SHA384
    Session-ID: D5EFECF89EB51CC305A7C7FCCEB87BEFF66E721F7FC76B30EDD85C2AB98E20E2
    Session-ID-ctx:
    Master-Key: FA04535FDDD30F767039382D4EED06AFEACDD29D109A795DAEF6DEC5E13F47A8F0FA0E135FED98376297B1BCE333A832
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    TLS session ticket:
    0000 - c2 80 77 50 cb 40 22 e3-11 0e ce f4 88 ea 38 8c   ..wP.@".......8.
    0010 - 64 fb 48 01 9c 37 be 4b-0e 95 13 88 90 06 4a ca   d.H..7.K......J.
    0020 - 91 ec c7 84 1a a1 4b 18-23 83 95 cf ff 45 27 9b   ......K.#....E'.
    0030 - cd 1d 69 0e fd 84 42 47-ba 39 13 cd 5b 4e 1e a3   ..i...BG.9..[N..
    0040 - fb 8a e3 8e 43 55 4a 27-a8 df 0f fd 8b f2 0f 30   ....CUJ'.......0
    0050 - 33 6a 42 0b 09 58 ea 41-7d e9 9e 9d 1b e6 bb 65   3jB..X.A}......e
    0060 - 84 1b 75 6d 13 c6 23 9b-b8 a6 f1 f9 00 e7 c8 3f   ..um..#........?
    0070 - ed b8 f1 44 a9 73 d1 ca-                          ...D.s..

    Start Time: 1517872786
    Timeout   : 7200 (sec)
    Verify return code: 21 (unable to verify the first certificate)
    Extended master secret: no
---
DONE

On v0.10.10

2018/02/05 23:20:29 [NOTICE] There is already a certificate loaded for , so certificate for [ ] will not service that name
2018/02/05 23:20:29 [NOTICE] There is already a certificate loaded for , so certificate for [] will not service that name
2018/02/05 23:20:29 [NOTICE] There is already a certificate loaded for , so certificate for [] will not service that name
Activating privacy features... done.
[INFO] Proxying from  :6697  ->  google.com:80
Done proxying: 172.18.0.2:6697 172.18.0.2:40090

$ openssl s_client -host localhost -port 6697 < /dev/null
CONNECTED(00000005)
140132566949824:error:1408F10B:SSL routines:ssl3_get_record:wrong version number:ssl/record/ssl3_record.c:252:
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 5 bytes and written 176 bytes
Verification: OK
---
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:
    PSK identity: None
    PSK identity hint: None
    SRP username: None
    Start Time: 1517872831
    Timeout   : 7200 (sec)
    Verify return code: 0 (ok)
    Extended master secret: no
---

I have attempted to bisect this bug, but found it impossible due to the inability to run bisections over the whole GOPATH. I can check out github.com/mholt/caddy at v0.10.6, add the plugin, and build but it fails just the same as v0.10.10. I suspect something has changed between august 2017 and now in the myriad of repositories in $GOPATH. Since there's no way to bisect all of these, i'm stuck using the v0.10.6 binary with no way to debug and no way to even reproduce the binary. I'm more than a little disappointed in the go tooling.

So i saw the config can redircet a PORT to a Website, but what is i wanna go the revers?
like redirecting port 22 on git.myserver.com to the local server LAN IP 10.0.0.121:22 as i have my website and Git server on two seperact servers so i dont loose everything if one breaks. it would be really nice

Latest Caddy version v1.0.0 (h1:KI6RPGih2GFzWRPG8s9clKK28Ns4ZlVMKR/v7mxq6+c=).

Caddyfile is:

proxy :3306 :3306 {
    tls off
    host global.dompbraywuid.us-west-2.rds.amazonaws.com
}

Starting with /usr/local/bin/caddy -log stdout -type=net -conf=/etc/caddy/Caddyfile

Activating privacy features...2019/05/02 22:03:34 [INFO][cache:0xc0000307d0] Started certificate maintenance routine
2019/05/02 22:03:34 [INFO] [global.dompbraywuid.us-west-2.rds.amazonaws.com] acme: Obtaining bundled SAN certificate
2019/05/02 22:03:35 [global.dompbraywuid.us-west-2.rds.amazonaws.com] failed to obtain certificate: acme: error: 400 :: POST :: https://acme-v02.api.letsencrypt.org/acme/new-order :: urn:ietf:params:acme:error:rejectedIdentifier :: Error creating new order :: Policy forbids issuing for name, url:

Huh? I am explicitly turning tls off.

I'm trying to proxy tcp traffic to different servers depending on which domain has been used. Basically a simple tcp reverse proxy.
When not specifying a domain, this works great - but only for a single server:

proxy :25565 192.168.14.10:25565 {
  host test1.domain.com
  tls off
}

This also, despite having "host" configured as a single domain, proxy's all traffic hitting the WAN-IP with port 25565.

Now, when trying to proxy different domains to different servers like this:

proxy test1.domain.com:25565 192.168.14.10:25565 {
  host test1.domain.com
  tls off
}

I'm getting the following error: Listen: listen tcp [WAN-IP-HERE]:25565: bind: cannot assign requested address
Since the host-directive doesn't seem to do anything, stuff like

proxy :25565 192.168.14.10:25565 {
  host test1.domain.com
  tls off
}

proxy :25565 192.168.14.11:25565 {
  host test2.domain.com
  tls off
}

also doesn't work: Listen: listen tcp :25565: bind: address already in use

Have I just done something wrong or is there an issue with the proxy?

Rather use github.com/google/tcpproxy library to do the proxying.

Hello,

Not really an issue, but just a confirmation that I'm doing things right and not messing things up!

I want to use caddy as a frontend server, redirecting everything that gets inside my network (after passing my router), and also centralizing the management of SSL certificates for my domain. (I actually have two caddy instances, one type=http & one type=net, sharing the same certificates).

I have a maildock instance, that was, until then, referring the SSL certs for the starttls connection for IMAP.

Now that I started my frontend instance of caddy-net, I figured that I had to reconfigure my STARTTLS IMAP connection to a SSL imap connection (still using the IMAP port, i.e. 143, though by default it should be 993).

Here's my configuration:

proxy :143 maildock:143 {
  host mydomain.net
  tls [email protected]
}

Is it ok or am I doing something wrong?

To me, the difference in my layman terms is the following:

• with starttls, the unencrypted dialog with IMAP starts, and then the tunnel is created
• with caddy-net, the dialog needs to be first encrypted.

The only problem is that now, it is possible to access the IMAP server directly in cleartext from my network, which for me is not a big issue.

Caddy's import path (and Go module name) has changed from

github.com/mholt/caddy

to

github.com/caddyserver/caddy

Unfortunately, Go modules are not yet mature enough to handle a change like this (see https://golang.org/issue/26904 - "haven't implemented that part yet" but high on priority list for Go 1.14) which caught me off-guard. Using Go module's replace feature didn't act the way I expected, either. Caddy now fails to build with plugins until they update their import paths.

I've hacked a fix into the build server, so downloading Caddy with your plugin from our website should continue working without any changes on your part, for now. However, please take a moment and update your import paths, and do a new deploy on the website, because the workaround involves ignoring module checksums and performing a delicate recursive search-and-replace.

I'm terribly sorry about this. I did a number of tests and dry-runs to ensure the change would be smooth, but apparently some unknown combination of GOPATH, Go modules' lack of maturity, and other hidden variables in the system or environment must have covered up something I missed.

This bash script should make it easy (run it from your project's top-level directory):

find . -name '*.go' | while read -r f; do
	sed -i.bak 's/\/mholt\/caddy/\/caddyserver\/caddy/g' $f && rm $f.bak
done

We use this script in the build server as part of the temporary workaround.

Let me know if you have any questions! Sorry again for the inconvenience.

I'm not able to install the plug in, neither via the caddy download page nor through the direct links.

This is in reference to problem mentioned in #2.

When multiple entries in Caddyfile is specified then only the last entry is started by Caddy

Good morning,

I was wanting to give the net plugin a quick test to see if it would work for proxying a database connection but I may doing things incorrectly so I wanted to check in and see if I'm doing things right.

What I'm trying to do is have a TCP proxy server send database connections to our Oracle Database, which uses Port 1521 for communication.

So we have 3 machines in my test:

• oracle-db (this is where the actual database is running)
• tcp-proxy (this is where Caddy is running)
• workstation (this is where I'm testing creating a connection to the database)

So Caddy with the net plugin has been setup on the tcp-proxy machine and I currently have the following in my Caddyfile:

echo :1521 {
    host oracle-db
    tls off
}

proxy :1522 :1521 {
    host oracle-db
    tls off
}

When I start up Caddy it shows the following output on the command line:

$ caddy -type=net
Activating privacy features... done.
[INFO] Echoing on port  :1521
[INFO] Proxying from  :1522  ->  :1521

So I try initiating a database connection on Port 1522 from the workstation but it's not able to connect to the database and I've since tried some additional variations of the above Caddy file (removing the host, switching the echo port to be 1522 instead of 1521, etc. but either I run into an error mentioning I'm doing things incorrectly when I try to start up Caddy, or there's no change when trying to connect to the database).

I'm mainly hoping that this would serve as an easier to implement TCP Proxy than HA Proxy which doesn't have easy Windows support compared to Caddy, and it'd just be easier for me to implement things on a Windows Server in our environment if I can use Caddy with the net plugin instead.

Thank you for any assistance you might be able to provide!

Good morning, just wanted to reach out and ask if the development of Caddy v2 is being monitored by yourself and if there is a plan to rebuild the net plugin so it is available for v2?

I'm utilizing the net plugin for a pretty key capability right now on my end with Caddy v1 and would like to switch to Caddy v2 once available, but not sure if the net plugin will be available anytime soon for v2?

If TLS is enabled then the domain name is sent as part of SNI. This could be used to allow serving from a single port and proxying to many others depending on who the host is.

Is this use case possible today?

If not, what would it take to be implemented? What needs to change?

Thanks!

Hello,

I have the tried the following:

proxy 25: smtpserver:25 {
  host mx.mydomaine.net
  tls off
}

With a configuration as such: router:25 -> frontend:25 -> smtpserver:25

I just noticed that with this setup, my smtp server was acting like an openrelay, which as per my postfix is normal if the requests come from my "internal network".

Redirecting the nat on my router (with masquerade) as follow solved the issue:
router:25 -> smtpserver:25

Hey there,

is there a possibility to use netcaddy to proxy all ports coming in on a specific interface to another host? This would be an alternative to using SNAT/DNAT iptables rules.

TLS setup calls need to change to suit @mholt 's new certmagic api