bug-wget
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Bug-wget] [Bug-Wget] Patch Test-proxied-https-auth.px


From: Tim Ruehsen
Subject: Re: [Bug-wget] [Bug-Wget] Patch Test-proxied-https-auth.px
Date: Thu, 30 Oct 2014 12:06:18 +0100
User-agent: KMail/4.14.2 (Linux/3.16-3-amd64; KDE/4.14.2; x86_64; ; )

On Thursday 30 October 2014 10:55:49 Daniel Stenberg wrote:
> On Thu, 30 Oct 2014, Tim Ruehsen wrote:
> > How the test should work:
> > - client open plain connection to proxy
> > - client sends CONNECT request
> > - server answers 200 OK
> > - client/server change to SSL on the existing connection (in the real
> > world
> > the proxy does this when it established the requested connection to the
> > outer world)
> 
> Not exactly. The proxy can't do it on its own. HTTPS is designed[*] to work
> peer to peer so it has to be the client to the server and the proxy is only
> setting up the tunnel but can't do the SSL stuff.

Thanks for clarification (sorry for my sloppy writing).

> > Of course the proxy could send a 'Proxy-Connection: close' with the first
> > 401 answer and close the connection. For this case I create a second test
> > case later.
> 
> A proxy won't be able to show you anything in the SSL connection as that is
> a tunnel to the server. If the proxy wants authentication it sends a 407
> instead of the initial 200, and that connection can of course get closed as
> well.

That's a good point for another test to set up (or maybe Test-proxy-auth-
basic.px is doing that, I have to look at it).

> [*] = at least originally, until the MITM-ing proxies entered the scheme and
> complicated matters, but I prefer to view that as messed up SSL and not
> "real" SSL =)

Yes, however, Wget has to be able to work with these (if users request it).

Thanks for sharing your well-founded knowledge.

Tim

Attachment: signature.asc
Description: This is a digitally signed message part.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]