On 03/25/2019 01:08 PM, openssl-users-request@xxxxxxxxxxx digested: > Date: Mon, 25 Mar 2019 11:33:55 +1100 > From: Abdul Qoyyuum <aqoyyuum@xxxxxxxxxxxxxxxxx> > > GET /images HTTP/1.0 Note that this is a HTTP 1.*0* request that doesn't require the client to send a Host: header stating what *his* idea of "which server am I trying to talk to?" is. > HTTP/1.0 301 Moved Permanently > Location: https://10.240.123.1:10443/images/ /images is a directory, which means that the client is supposed to ask for "/images/" (with a trailing slash) to request a directory listing. The server is helpfully sending back a HTTP Redirect to tell the client what he *should* request instead, in the form of a complete URL, which necessitates a host and port part. Having no idea who and what the *client* expects to talk to, the server fills in what *it* knows - its local (internal) IP and port. This "attack" already worked that way almost 20 years ago, when I demonstrated it to some (horrified) bank IT people on their Netscape-based online banking solution middleware ... OpenSSL is not involved here, and whether (and what) you can do to close the gap depends on what HTTP server (and, if present, reverse proxy solution) you're using. Regards, -- Jochen Bern Systemingenieur www.binect.de www.facebook.de/binect
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
