Re: relayd https inspection certificate issue

2023-12-20 Thread J Doe

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

2023-12-11 Thread Philipp Benner
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

2023-12-09 Thread J Doe

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

2023-12-09 Thread Claudio Jeker
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



relayd https inspection certificate issue

2023-12-08 Thread Philipp Benner
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?

 
Thank you very much!