bug-wget
[Top][All Lists]
Advanced

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

RE: [Bug-wget] (no subject)


From: Tony Lewis
Subject: RE: [Bug-wget] (no subject)
Date: Tue, 28 Jul 2009 16:10:20 -0700

Micah Cowan wrote:

> I disagree with Tony's statement: unless you're having wget spit out
> information about what the certificate _is_, how can you claim to
> "trust" it? 

I think it is likely that people will be using wget to retrieve content from
web servers in which they already some pre-existing trust. (Granted, that
trust may not be grounded in reality, but it probably already exists.)

Using --no-check-certificate is akin to clicking a button in a web browser
to trust the server's certificate. Most users do not the technical expertise
to evaluate the validity of such certificates before accepting them in the
web browser or wget.

Nevertheless, all other aspects of SSL/TLS are honored by both the browser
and wget when the user chooses to accept the certificate. (However, see the
discussion of the "bug" mentioned below.)

> What you're not assured, is _who_ the remote is. Authentication
> is an essential component of security.

Yes, and there is the potential that the typical user is subject to a
man-in-the-middle attack when accepting self-signed certificates or any
other certificate that cannot be verified by the client (browser or wget).

> With --no-check-certificate, the connection is explicitly insecure.

That ultimately depends on whether the certificate is in fact a valid for
the server from which the user is requesting some content. If it is a valid
certificate for that server, the connection is just as secure as it would be
for a session in which wget can verify the certificate.

Using --no-check-certificate transfers the trust in the certificate from the
digital signature of a remote certificate authority to the user.

> Though if
> you know for a fact that a particular certificate is valid, it'd still
> be better to make an explicit exemption for that one certificate, rather
> than a blanket "don't worry about it" (unfortunately, wget doesn't
> currently offer such a facility: I'll file a bug).

An excellent point; there should probably be a mechanism for the user to
express trust in a specific certificate (either for a single session or
permanently). If the wget session is following links to another server,
there is the potential for havoc. At a minimum --no-check-certificate should
probably only apply to servers that are explicitly mentioned on the command
line and/or input file.

Tony





reply via email to

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