Re: WinInet/AfxInet -- authenticate server
- From: "Raul Igrisan" <green@xxxxxxxxxx>
- Date: Wed, 30 Nov 2005 11:36:38 +0200
"Eugene Gershnik" <gershnik@xxxxxxxxxxx> wrote in message
news:uCLFFdQ9FHA.1484@xxxxxxxxxxxxxxxxxxxxxxx
> Raul Igrisan wrote:
>> "Eugene Gershnik" <gershnik@xxxxxxxxxxx> wrote in message
>>> But that's exactly what should be checked built-in as I wrote above.
>>> If you say to a library that supports SSL "connect to
>>> https://x.y.com" it should validate the certificate *and* check that
>>> its CN says "x.y.com". I don't know about WinInet but .NET certainly
>>> does just this. If the name is not x.y.com the connection attempt
>>> will fail. There are usually options to *override* this behavior but
>>> the default is just what you are looking for. Did you actually check
>>> what happens if you connect with WinInet to a host that supplies a
>>> certificate with different name?
>> This is not secure enough for me. The user could generate a CA
>> certificate for x.y.com, add it in the default certificate store as a
>> trusted certificate,
>
> Now waaait a second. If the malicious *server* admin can get to the
> *client* machine and install a certificate in its trusted storage then you
> are already hacked and done with. Nothing in SSL or any other technology
> will help you here. (My next step would be to redirect your Windows Update
> communication to my site and download a nice and clean rootkit to the
> machine. Then disable whatever other level of "protection" you may have)
again I agree but that's not our topic :)
>
>> install
>> it on his webserver, mess up the DNS so x.y.com would point to his
>> server, and, voila, my application would not connect to the server I
>> really wanted it to connect.
>
> There is nothing that can help you in the scenario you describe. If on the
> other hand the *client* cert store is trusted then you have no problem.
> The certificate for "x.y.com" generated by malicious admin will no be
> trusted and the connection attempt will fail.
The default client cert store is not trusted, a smart user might generate
certificates and than trick my app to connect to his server or tunnel my
connection. So I need to *ovverride* the default trust store.
>
>> I hope now it is clear enough why do I need to *override* the default
>> behavior (the default trusted cert store) or add some extra check to
>> see if the server is really the one I intended to connect.
>
> No it is not clear. If you don't trust your *client* SSL infrastructure
> you should specify what you do trust. No computer security analysis is
> possible without having some parts of software/hardware explicitly
> trusted.
I don't trust the *user*. I don't want a smart user to trick my application
to connect to a server other than ours. Still confusing?
.
- References:
- WinInet/AfxInet -- authenticate server
- From: Raul Igrisan
- Re: WinInet/AfxInet -- authenticate server
- From: Eugene Gershnik
- Re: WinInet/AfxInet -- authenticate server
- From: Raul Igrisan
- Re: WinInet/AfxInet -- authenticate server
- From: Eugene Gershnik
- Re: WinInet/AfxInet -- authenticate server
- From: Raul Igrisan
- Re: WinInet/AfxInet -- authenticate server
- From: Eugene Gershnik
- Re: WinInet/AfxInet -- authenticate server
- From: Raul Igrisan
- Re: WinInet/AfxInet -- authenticate server
- From: Eugene Gershnik
- WinInet/AfxInet -- authenticate server
- Prev by Date: Re: Completion Port issue
- Previous by thread: Re: WinInet/AfxInet -- authenticate server
- Next by thread: Re: Is HTTP API V1.0 support multiple HTTP request on the same URL
- Index(es):
Relevant Pages
|