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 15:14:04 +0100
User-agent: KMail/4.14.2 (Linux/3.16-3-amd64; KDE/4.14.2; x86_64; ; )

On Thursday 30 October 2014 14:43:58 Daniel Stenberg wrote:
> On Thu, 30 Oct 2014, Tim Ruehsen wrote:
> >> [*] = 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).
> 
> From how I understand things, most HTTPS-MITMing proxies are the
> intercepting transparent kind that will sit in your company/organization
> network and as soon as you want to connect to TCP:443 somewhere, the MITMer
> will accept that connection and fake back a cert for the client and then
> connect to the remote server and then sit in the middle of that
> conversation.
> 
> The only thing wget needs to support that scenario is the CA cert for the
> certs the proxy generates on the fly. Or just skip the check and silently
> accept everything.

Maybe each client having only just one (the companies) CA cert to SSL connect 
with the proxy. To have a max of security (e.g. CA and CRL administration done 
at the proxy).
Together with client certificates, so you can admin the internet access rights 
also from a central position very easily.
The traffic would be SSL encrypted in the intranet, but still completely 
visible at that central point.
Goodbye private internet, +1 to George Orwell's view :-(
From what I read, this is reality in many companies.

Tim

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


reply via email to

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