The first few bytes on a new TLS connection will be the record layer bytes denoting a handshake and the TLS version field, so 0x160301 or 0x160303. ASCII-based proxy protocol v1 will start out 0x5052 etc, and binary-based proxy protocol v2 has its own initial 12 byte signature of 0x0D0A0D0A etc.(documented here https://www.haproxy.org/download/1.8/doc/proxy-protocol.txt). You could handle all three plus plaintext http on the same port if you felt so inclined.
-eli > On Apr 26, 2024, at 3:40 AM, 'Brian Candler' via golang-nuts > <golang-nuts@googlegroups.com> wrote: > > Really I was unsure whether you can guarantee that the first few bytes of a > TLS "client hello" can never happen to be the ASCII characters P R O X Y .... > As a binary protocol I think it's unlikely to occur, but I've not attempted > to prove it. > > On Friday 26 April 2024 at 02:30:51 UTC+1 Eli wrote: >> > And whilst HTTP is a text protocol (and can distingush between PROXY and >> > GET/POST/PUT etc), what about TLS? >> >> Proxy protocol is sent as the first bytes on wire after TCP is established, >> not carried via HTTP headers, so it is easily distinguishable from TLS. >> >> I agree with all other points, but wanted to mention that. 🙂 >> >> -eli >> >> >> On Monday, April 15, 2024 at 4:43:50 PM UTC-4 Brian Candler wrote: >> > My point is that a http server that is using the standard library always >> > reply with an "HTTP/1.1 400 Bad Request" when the proxy protocol is part >> > of the tcp package. >> >> That's the correct response, because the request is not compliant with HTTP. >> >> > So the net/http should just handle the http request like they do without >> > the proxy protocol. >> >> Why should it do that? It would mask a configuration error - either that the >> upstream device is sending with proxy protocol when it should be sending >> plain HTTP, or that the downstream server has not been configured correctly >> to interpret the proxy protocol. >> >> At worst, it would open security problems, when the upstream proxy *thinks* >> it is successfully passing along source IP address information, but the >> downstream server is ignoring it. >> >> Can you point to any other well-known HTTP server implementation which >> ignores inserted PROXY headers like this? I know that Apache doesn't: you >> have to configure each vhost to either use or not use proxy protocol. >> https://httpd.apache.org/docs/2.4/mod/mod_remoteip.html#remoteipproxyprotocol >> >> And whilst HTTP is a text protocol (and can distingush between PROXY and >> GET/POST/PUT etc), what about TLS? >> >> On Monday 15 April 2024 at 21:06:37 UTC+1 HappyTobi wrote: >> Hi, >> >> thanks for the answer, but thats not the point. >> I think it's fine to use a library or implement something to add something >> to the http layer to parse the proxy protocol. >> >> My point is that a http server that is using the standard library always >> reply with an "HTTP/1.1 400 Bad Request" when the proxy protocol is part of >> the tcp package. >> So the net/http should just handle the http request like they do without the >> proxy protocol. >> If someone needs to parse the proxy protocol, it's fine to implement or add >> a 3rd party lib, but I think the "default" should just work. >> >> Brian Candler schrieb am Montag, 15. April 2024 um 20:41:50 UTC+2: >> Your answer was given here: >> https://github.com/golang/go/issues/65078#issuecomment-1890419683 >> >> In other words: >> - net/http handles HTTP >> - go-proxyprotocol handles the proxy protocol >> - you combine the two to get the behaviour you want >> >> Orthogonal pieces which handle their own responsibilities are a Good Thing™ >> IMO. >> >> If you want to wrap this up in a library which has the same API as net/http >> but implements proxy protocol, you are free to do so (and publish it, if you >> wish). However, there is a very high bar for putting functionality into the >> core Go library, because the backwards compatibility promise means it has to >> be supported forever. >> >> > I have previously posted two issues on this topic, but neither has been >> > accepted >> >> I think that answers your question. >> >> On Monday 15 April 2024 at 17:47:24 UTC+1 HappyTobi wrote: >> Dear Gophers, >> >> I would like to bring to your attention. >> There is an “issue” with the Go standard implementation when handling HTTP >> requests that are extended by the proxy protocol v1 or v2. >> >> While the simple HTTP server works fine with regular requests, it fails when >> a proxy protocol is added. >> >> Example: >> Simple http server: >> package main >> >> import ( >> "fmt" >> "net/http" >> ) >> >> func hello(w http.ResponseWriter, req *http.Request) { >> fmt.Fprintf(w, "hello world\n") >> } >> >> func main() { >> http.HandleFunc("/hello", hello) >> http.ListenAndServe(":8080", nil) >> } >> The server is working fine when you do something like: >> curl -kv http://localhost:8080/hello >> >> But the implementation is failing when you add a proxy protocol (v1) to the >> tcp request. >> curl -kv --haproxy-protocol http://localhost:8080/hello >> >> The issue arises because the implementation fails to read the HTTP message, >> as the message starts with the proxy protocol. >> Go read request function: >> https://github.com/golang/go/blob/91c04826723a10f6778a935e743a34de81312489/src/net/http/request.go#L1068 >> >> >> The proxy protocol is widely used, and it would be beneficial for the Go >> standard implementation to handle such requests. >> >> I have previously posted two issues on this topic, but neither has been >> accepted. I would like to open a discussion on this topic and work towards >> implementing a solution that could be merged into the Go standard library. >> Your input and feedback is more than welcome! >> >> Thank you all. >> >> Github issue links that I posted: >> net/http: Http Server (request) is not working with enabled Proxy Protocol · >> Issue #64365 · golang/go (github.com) >> <https://github.com/golang/go/issues/64365> >> proposal: net/tspsock: filter/interceptor - concept with default >> implementation for proxyprotocol (v1/v2) · Issue #65078 · golang/go >> (github.com) <https://github.com/golang/go/issues/65078> > > -- > You received this message because you are subscribed to a topic in the Google > Groups "golang-nuts" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/golang-nuts/Uvq-BlNLSOM/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > golang-nuts+unsubscr...@googlegroups.com > <mailto:golang-nuts+unsubscr...@googlegroups.com>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/golang-nuts/4e914729-9d97-4822-83e6-6bceee907b2cn%40googlegroups.com > > <https://groups.google.com/d/msgid/golang-nuts/4e914729-9d97-4822-83e6-6bceee907b2cn%40googlegroups.com?utm_medium=email&utm_source=footer>. -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/D96CCE21-7147-4E68-891D-9E34F5C5F83F%40siliconsprawl.com.
