Replies: 8 comments 3 replies
-
Hi Róbert, I'm afraid I don't quite understand the proposed use case. Whatever method the backend uses for managing its certificate, it can always be configured as a regular backend using the |
Beta Was this translation helpful? Give feedback.
-
Yes, but the problem is, that pound's certificates are not the same as the ones the backend has. The backend has its own certificate, the traffic should not be (re-)encrypted by So I have a backend with a different set of certificates, which I need to access through pound. Pound would have to just proxy back and forth those packets to the backend just like they would be plain HTTP packets, not via port 80, but via port 443. |
Beta Was this translation helpful? Give feedback.
-
The backend has its own certificate, the traffic doesn't have to be
(re-)encrypted by pound again (and I think it would run in an error
anyway).
It is a normal practice, there would be no error in this case.
So I have a backend with a different set of certificates, which I need
to access through pound. Pound would have to just proxy back and forth
those packets to the backend just like they would be plain HTTP packets,
not via port 80, but via port 443.
There is a principal difference between processing plain HTTP and opaque
stream of bytes: in first case the content of the requests is analyzed
and used to decide how to process it. In the second case, nothing of
this is possible. In particular, it is not even possible to know
whether the sending party has stopped transmission (vital in case of
HTTP/1.1).
What you describe is better be handled on layer 3 or even 2, level, e.g.
using port forwarding.
|
Beta Was this translation helpful? Give feedback.
-
So you say if create a service in pound, under the https listener,
pointing to an internal backend at port 443 serving already https,
that will be transparently passed through?
Yes, of course. All you have to do is to mark the backend as https,
like this:
```
Backend
Address 192.0.2.1
Port 443
HTTPS
End
```
|
Beta Was this translation helpful? Give feedback.
-
Didn't know that. Lemme test it. The doc is a bit misunderstandable because all it has is:
This being in context of |
Beta Was this translation helpful? Give feedback.
-
You interpreted that correctly. That's exactly what pound is doing in this case. |
Beta Was this translation helpful? Give feedback.
-
Then try the "transparent" branch. It implements the TransparentProxy section (see NEWS for a description), which, as far as I can tell, does what you want. Let me know if t works for you. |
Beta Was this translation helpful? Give feedback.
-
No, of course it cannot. To do so one must finish TLS handshake first. That requires having valid certificate, which we don't. On the other hand, once TLS handshake finished, the data cannot be proxied to the backend without reencryption. |
Beta Was this translation helpful? Give feedback.
-
Would it be possible to implement a kind of raw data service, where HTTPS would be transferred from port 443 down to the backend directly, pretty much like
socat
does, without adding any encryption layer?The use case would be for when certain appliances as backends do their own certificate management (eg. they user their own Let's Encrypt routines) and add their own HTTPS layering. We can't forward them to the same 443 port as Pound already occupies this port. The challenge part can already be done by preceeding the ACME service with the ones that need to be transferred furnther down.
This kind of raw service would only use the match options, but would not add the encryption, but just instead transfer the data back-and forth like
socat
.Beta Was this translation helpful? Give feedback.
All reactions