[Remops] Oops! Small problem!

[richard at quicksilvermail.net]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Wed, 5 Nov 2014 11:21:46 +0000, you wrote:
>
>
> --===============0885942309238135529==
> Content-Type: multipart/signed; micalg=pgp-sha256;
> 	protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG"
> Content-Disposition: inline
>
>
> --OgqxwSJOaUobr8KG
> Content-Type: text/plain; charset=utf-8
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Tue, Nov 04, 2014 at 11:55:42AM -0700, richard at quicksilvermail.net wrote:
> >=20
> > On Tue, 4 Nov 2014 15:36:23 +0000, you wrote:
> > >
> > > Hi Richard,
> > >
> > > I think the URLDownloadToFile function uses the same certificate store
> > > as Internet Explorer so it might be a case of telling IE to accept
> > > certain self-signed certificates.  I found these instructions on how to
> > > do that:-
> > > http://stackoverflow.com/questions/681695/what-do-i-need-to-do-to-get-i=
> nter=3D
> > > net-explorer-8-to-accept-a-self-signed-certific
> > >
> > > I've tested this from within IE but don't have another URLDownloadToFile
> > > binary to test my theory against.  Might be worth a try with your 3.03a
> > > binary.
> >=20
> > Hi Steve,
> >=20
> > The instructions you show me describe how to get windows to accept self-
> > signed certs on MY computer. You wish this to be applied to all
> > mixmaster users? This can likely be done programatically, but I don't
> > see how, without an installation program.
> >=20
> > I often miss the point completely :) Am I missing your point?
>
> Hi Richard,
>
> Not sure if you missed my point, or that I didn't make it.  :)
>
> I don't think there is a programmatic solution for telling
> URLDownloadToFile to ignore the certificate chain.  Its behaviour is
> identical to the IE browser in that it requires a valid certificate
> chain, or a conscious decision by the user to create an exception.

This is not news to me. URLDownloadToFile actually calls IE do the
download, so requirements are identical.

I believe if I had a newer version of VC++, URLDownloadToFile could
ignore the cert problem. There are a number of flags regarding this.

> For example:
> https://www.mixmin.net/echolot/ is not self-signed but will probably
> fail because IE doesn't include (by default) a root certificate for
> cacert.org.  If a user wants my stats via HTTPS, they'll either need to
> create an exception or add the cacert root to their certificate store.
>
> This behaviour is consistent with most applications that use x.509
> certificates so I'm inclined to think we shouldn't change it, even if we
> could.  Better to let each user make a conscious choice to accept
> certificates that don't have verifiable chains.

I agree completely. If URLDownloadToFile had worked as expected--
ignoring the problem--I would be happy with that, but I think installing
invalid certs on user's computers is a very, very bad idea. I'm glad
we're on the same page here.

Unfortunately, the user cannot decide to accept the certs since they get
no chance to do that. But we have what we have. The problem is not
windows and not mixmaster. The problem is invalid certificates and if
anything is fixed, it should be that.

It's a real break that mix CAN download allpingers.txt from github!

BTW I'm using the latest 3.0.3a code and the only change I've made to
the code is add 's' to http.

Richard

-----BEGIN PGP SIGNATURE-----
Version: N/A

iQIcBAEBAgAGBQJUWoihAAoJEJxtYUVddaeif8wP/RtJ+lXBLGV0W2328zMp8mrX
W2YzsMfmysH/Hoil6vNF1nRsJMiiEzcbwoVMzEUveyChtrdkVe2QeSX3HJOY3m05
T+/qVK8Czh+mIrl4b/asCAhyTVJMo2hZrU7Y/Wad5p6GeWDQn711assPKjNwSmfv
Ur/CLnaJ36h2HRe0uB7x7ZSHUc1PbNendNk5I3n2Ykn+l3RosSNUCUMHt/BY65Nn
6S/jhWivDwgGHIDFQ9iAKV18FjlF4EVF47Q4bdiz/vIwtmQskKQ+Fh+9Mj+eZamg
MVKCF7QKp6JnzsETEFsRVjPqjfaPT5SWinACSSUpqJ5E72RDgALfj+2sFPSmGlQx
IXBpaoo5Mv09d+AbfTSRrN3GMQFAWt/brzptWKtmhYAISi03djcD/MVSYV1b3tPz
4OrCW+MSME+5sZZR4dN6T12ANPjUeOi7VfudM2mLftZBAH4OLob/vbVxD1CI7CaZ
lh+EiDzBp6PVCb40g7p6NOTGkb6jfdQeYlwmsY5o3HFn/S5mS0bAlbJ92t7EWpxh
ycxjVhGNHoXAUl4YIMuU3w5OtiEbCdp8ao30LeRVlwSXc4oV9I6bBJcdJFg3NTe3
Y6mlL1lXPDqRH0OaQL6BnOhGE0up2bb6HU7TiD7Er4Xu+YTet/IXJvu7ibiLCT4+
OL0jMk52Akh0XS+EiT32
=oMZL
-----END PGP SIGNATURE-----