New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proxy to a remote server with the remote using self signed certs fails. #320

Closed
pschlump opened this Issue Nov 5, 2015 · 10 comments

Comments

Projects
None yet
5 participants
@pschlump
Copy link

pschlump commented Nov 5, 2015

Suppose that you have caddy running as a reverse proxy to a 2nd server. Caddy will return
an error if the 2nd server has self signed certificates.

Caddyfile:

https://localhost:3223 {
    tls /Users/corwin/Projects/ws2/samp-key/cert.pem /Users/corwin/Projects/ws2/samp-key/key.pem
    proxy /static https://www.test2.com:9443/
}

Suppose that https://www.test2.com:9443/ is a server running with self-signed certificates.
You get the error:

2015/11/05 09:00:00 http: TLS handshake error from 192.168.0.158:56996: remote error: bad certificate

The :9443 server is in Go with HTTP2.0. I can provide the source code for it if you need it.

@pschlump

This comment has been minimized.

Copy link
Author

pschlump commented Nov 5, 2015

It looks to me like the default is for it to check that the certificate is valid. I am working on some code
that sets the flag to make it not check.

@mholt

This comment has been minimized.

Copy link
Owner

mholt commented Nov 5, 2015

@pschlump Check out

upstream, err := url.Parse("https://" + r.Host + ":" + alternatePort)
if err != nil {
return http.StatusInternalServerError, err
}
proxy := httputil.NewSingleHostReverseProxy(upstream)
proxy.Transport = &http.Transport{
TLSClientConfig: &tls.Config{InsecureSkipVerify: true}, // client uses self-signed cert
}
proxy.ServeHTTP(w, r)
for an example; it may be helpful.

I feel like this verification is important, though, and should be on by default.

@solderjs

This comment has been minimized.

Copy link
Contributor

solderjs commented Nov 5, 2015

@pschlump You SHOULD NOT use self-signed certificates DIRECTLY. You MUST use them INDIRECTLY.

See

You just need to add 3 steps to your process:

  • create a second private key (you've done this before)
  • create the csr for that private key
  • sign the second private key with the first self-signed certificate

What caddy does need, @mholt, is a way to specify the pool of trusted cas.

   tls <cert> <key> <clientca-certpool>
   proxy <rootca-certpool> ...

Edit: changed the clientca / rootca location (I think I got it right now)

See https://golang.org/pkg/crypto/tls/#Config RootCAs / CertPool

This is most useful in a business / enterprise environment where the user only wants to trust their local authority, not

@mholt

This comment has been minimized.

Copy link
Owner

mholt commented Nov 6, 2015

This is most useful in a business / enterprise environment where the user only wants to trust their local authority, not

The suspense is killing me 😆

I think this issue needs some careful consideration. Disabling cert verification may be acceptable in dev/test environments, and should probably be an option anyway. Adding to the trust store is a separate matter.

@solderjs

This comment has been minimized.

Copy link
Contributor

solderjs commented Nov 6, 2015

not the global authorities.

I don't believe that disabling cert verification should ever be an option. I think that instead there should be a FAQ "how do I disable cert verification" and then a "you don't need to, run this command instead and add this line to your config file".

I would be very happy to finesse my self-signed authority / cert scripts and publish that material.

The belief that a person needs to disable cert verification - even during testing - stems from very popular tutorials with misinformation regarding the matter.

@rtreffer

This comment has been minimized.

Copy link

rtreffer commented Jan 11, 2016

Hm, I somehow disagree with the talk on this page.... Let me explain my situation....

I'm exposing some services at home. I have native IPv6 (changing prefix) and IPv4 (changing single ip) connectivity. I'm regularly updating a DNS zone.

Wherever possible I'm using the IPv6 addresses as this will mean I can reach my services directly if I'm at home.
Caddy is used to provide a https proxy for IPv4 connectivity. (basically stuff like <service>.<mydomain> -> <service.local>)

Some services like subsonic generate a redirect to https (for good reasons!) which means I have to proxy to the https port or I'll just get 30X responses.

I am using self signed certificates at home.

I'm now running an apache proxy just to get rid of this caddy mess. The "solution" to run an internal CA is a bit overkill for a home network.
(And - as a side note - there is absolutely no need to write tools for that. OpenVPN comes with easyrsa, a simple wrapper to generate CAs. But I still think this is pure overkill for a home network PLUS it would open MITM if I ever loose the key, causing a whole array of different issues like how do I safeguard that key)

@FiloSottile

This comment has been minimized.

Copy link
Collaborator

FiloSottile commented Jan 23, 2016

Caddy will let you use plain HTTP upstreams, so there is no reason at all not to let a user disable verification (which should be on by default).

I'll make it easy and add a generic insecure_skip_verify option.

BTW, the fact that upstreams can be HTTPS is not documented AFAICT.

@mholt

This comment has been minimized.

Copy link
Owner

mholt commented Jan 23, 2016

@FiloSottile Yeah you're right. It should be allowed if the user explicitly enables it. And no, it's not obvious in documentation; since it just kind of 'works' I didn't bother to put it in the docs, but couldn't hurt.

Thanks for the PR!

@rtreffer

This comment has been minimized.

Copy link

rtreffer commented Jan 23, 2016

The use of upstream HTTPs is documented, but the hint is well hidden:

to is the destination endpoint to proxy to. At least one is required, but multiple may be specified.
If a scheme (http/https) is not specified, http is used.

@rtreffer

This comment has been minimized.

Copy link

rtreffer commented Jan 23, 2016

I just tried the patch in my home network and it works as expected. Thank you!

Am 23. Januar 2016 06:36:15 MEZ, schrieb Matt Holt notifications@github.com:

@FiloSottile Yeah you're right. It should be allowed if the user
explicitly enables it. And no, it's not explicitly documented; since it
just kind of 'works' I didn't bother to put it in the docs, but
couldn't hurt.

Thanks for the PR!


Reply to this email directly or view it on GitHub:
#320 (comment)

Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail gesendet.

@mholt mholt closed this in bae4ac9 Jan 23, 2016

mholt added a commit that referenced this issue Jan 23, 2016

Merge pull request #529 from FiloSottile/filippo/insecure
proxy: add a insecure_skip_verify option - closes #320
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment