Closed kirkeide closed 4 years ago
@fetep
Hi @kirkeide - the ssl_exporter operates at TCP level, so HTTP_PROXY
and HTTPS_PROXY
(or http_proxy
and https_proxy
) won't work. If you were to run a TCP proxy then you could probably use ALL_PROXY
.
The switch from HTTP to TCP was a recent change in order to support non-http SSL endpoints (like ldaps://
). I could add a flag, or an argument to /probe
, to allow toggling between tcp and http but I'm kind of divided on whether that is a good idea or not. My initial preference is always to keep things as simple as possible.
That being said, http proxying is quite common and not always avoidable and it might be helpful to support it.
+1 for supporting it, but I do understand the desire to keep things simple.
Hi, @kirkeide. Sorry for the delay - life has been pretty hectic recently.
After some thought, I’ve decided to reinstate the http client, which will make proxying possible.
My favoured approach to this problem would be to use the target’s address to signal to the exporter what kind of connection to make to the target. I think this makes sense. If you’re using https://
in the URL, you would naturally expect that the connection is made over https.
What the exporter is doing now, converting that address to the format <target>:443
and making a tcp request, is actually somewhat dishonest and leads to exactly the kind of confusion in this ticket. If you’re using the format https://<domain>
you would probably expect https proxying with HTTPS_PROXY
to work, just like it would with curl.
In cases where a port and no scheme is given (localhost:443
), I think we should continue to operate as a TCP client. If neither is given, I think it’s safe to default to what I imagine is overwhelmingly the most common case (https on port 443).
I’ve made an initial stab at this on this branch. It seems to work for me but could you test it in your environment?
Very cool. I agree with your approach and will test it as quickly as I can (but this may still take a few days to get done). Thanks!
I finally had some time to test this, but behind my work firewall I cannot easily pull down a functional go environment and needed dependencies. Can you create an artifact for linux_amd64 that I can test? Thanks!
@kirkeide Here you go: ssl_exporter-https-proxy.tar.gz
Thanks! -------- Original message --------From: Rob Best notifications@github.com Date: 8/20/19 4:42 AM (GMT-05:00) To: ribbybibby/ssl_exporter ssl_exporter@noreply.github.com Cc: Kirk Eide keide@xmission.com, Mention mention@noreply.github.com Subject: Re: [ribbybibby/ssl_exporter] Use HTTP Proxy (#8) @kirkeide Here you go: ssl_exporter-https-proxy.tar.gz
—You are receiving this because you were mentioned.Reply to this email directly, view it on GitHub, or mute the thread. [ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/ribbybibby/ssl_exporter/issues/8?email_source=notifications\u0026email_token=AIJFFORQYURKHUGMNBQJ4W3QFOU5XA5CNFSM4IHSXQTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4VRFYA#issuecomment-522916576", "url": "https://github.com/ribbybibby/ssl_exporter/issues/8?email_source=notifications\u0026email_token=AIJFFORQYURKHUGMNBQJ4W3QFOU5XA5CNFSM4IHSXQTKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4VRFYA#issuecomment-522916576", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]
After endless delays, I'm happy to say initial testing is working great! I will post any oddities or errors as we encounter them.
Thanks again!
Kirk
Great! I've released the changes as v0.6.0. Thanks for the issue and your help in testing.
Is it possible to enable the use of a HTTP proxy with the probe. I tried setting HTTP_PROXY and HTTPS_PROXY with no luck and I see no other way to specify one.
Would this be easy to add per target or via an argument to ssl_exporter?