Re: relayd https inspection certificate issue
On 2023-12-11 14:06, Philipp Benner wrote: Thank you for the infomation Claudio! What a pitty! I thought I found a tiny solution there. Do you have any suggestions for an alternative? I don'´t want to install squid becaus of limited ressources on this machine. Any ideas? Or should I try nginx? Hi list, Just wondering the same question - is there a open source TLS inspection proxy that anyone can recommend besides using relayd's functionality for this ? Thanks, - J
Re: relayd https inspection certificate issue
Thank you for the infomation Claudio! What a pitty! I thought I found a tiny solution there. Do you have any suggestions for an alternative? I don'´t want to install squid becaus of limited ressources on this machine. Any ideas? Or should I try nginx? Thank you! -Ursprüngliche Nachricht- Von: Claudio Jeker Gesendet: Samstag, 9. Dezember 2023 10:02 An: Philipp Benner Cc: misc@openbsd.org Betreff: Re: relayd https inspection certificate issue On Fri, Dec 08, 2023 at 10:04:25PM +, Philipp Benner wrote: > Dear all, > > > I would like to use relayd as an outbound https proxy, so I configured it > like shown in the last section of the relayd.conf(5) manpage. > > This works fine for e.g. wikipedia.org. The certificate issued by my relay is > nearly the same as the original, except oft he issuer of course. > > But when I try to visit e.g. heise.de, at least all images refuse to load. > After some research I found out the following. > > When visiting the site directly without proxy, I can see that the > images are loaded from https://heise.cloudimg.io. If I open an image > in a new browser, I can also see that the certificates applicant is > 2e26bae.cloudimg.io, alternative applicants are heise-aws.cloudimg.io > and heise.cloudimg.io > > Now if I use the relayd proxy and try to open an image in a seperate > browser, the url is the same https://heise.cloudimg.io/... but the > certificates is different. Its applicant now is a.248.e.akamai.net and > alternatively *.akamaized.net and some other *.akamai… > > So the self-issued certificate has completely other applicants than > the original and of course doesn‘t match the actual server name and I > get the error ERR_CERT_COMMON_NAME_INVALID > > > Can anybody help or give advice? Don't do it. This "TLS inspection" mode is broken and it is close to impossible to fix it. The way the MITM cert is built is not smart enough and does not consider many special cases like SAN certs and OCSP. It works for simple things but does not work as a generic SSL interceptor. -- :wq Claudio
Re: relayd https inspection certificate issue
On 2023-12-09 04:02, Claudio Jeker wrote: Don't do it. This "TLS inspection" mode is broken and it is close to impossible to fix it. The way the MITM cert is built is not smart enough and does not consider many special cases like SAN certs and OCSP. It works for simple things but does not work as a generic SSL interceptor. Hi Claudio and list, Ah, I was experimenting with this this week and couldn't understand why I was getting similar errors. I'd still like TLS inspection on one of my routers and while I usually try to stick with the tools that ship with each OpenBSD install, I was wondering if anyone could recommend any third party software with a good security track record ? I believe nginx can operate as a reverse proxy / application layer gateway ... can it also do TLS inspection for user traffic ? Thanks, - J
Re: relayd https inspection certificate issue
On Fri, Dec 08, 2023 at 10:04:25PM +, Philipp Benner wrote: > Dear all, > > > I would like to use relayd as an outbound https proxy, so I configured it > like shown in the last section of the relayd.conf(5) manpage. > > This works fine for e.g. wikipedia.org. The certificate issued by my relay is > nearly the same as the original, except oft he issuer of course. > > But when I try to visit e.g. heise.de, at least all images refuse to load. > After some research I found out the following. > > When visiting the site directly without proxy, I can see that the images are > loaded from https://heise.cloudimg.io. If I open an image in a new browser, I > can also see that the certificates applicant is 2e26bae.cloudimg.io, > alternative applicants are heise-aws.cloudimg.io and heise.cloudimg.io > > Now if I use the relayd proxy and try to open an image in a seperate browser, > the url is the same https://heise.cloudimg.io/... but the certificates is > different. Its applicant now is a.248.e.akamai.net and alternatively > *.akamaized.net and some other *.akamai… > > So the self-issued certificate has completely other applicants than the > original and of course doesn‘t match the actual server name and I get the > error ERR_CERT_COMMON_NAME_INVALID > > > Can anybody help or give advice? Don't do it. This "TLS inspection" mode is broken and it is close to impossible to fix it. The way the MITM cert is built is not smart enough and does not consider many special cases like SAN certs and OCSP. It works for simple things but does not work as a generic SSL interceptor. -- :wq Claudio
