SSL security authorization?

[Anand Pillai]

You are right, I was basically asking about server-side
authentication. My question was actually about the complete
ACK protocol taking place (the "handshake") between the client
and the server.

Ok, so server-side authentication is not there.I assumed so...:-)
The docs are very vague on this point actually.

Even then if we can write the client authentication, part of
the work would be done since we can assume that the server
credentials are valid for the time being. In such a case you
of course end up talking to a server whose identity you are not
sure of, but who has verified yours thru client authentication.

My scenario was too advanced for the existing state of urllib
or urllib2, since it deals with HTTPS password authentication
on the server side. It cannot be done in the current state since
that needs the server authentication code to be present in 
ssl.pyd, which as you say is not there.

Ah, let us try to get the client ACK working first. 

My doubts are clarified.

I will start this on Monday since I am on a short vacation
owing to local celebrations.

Thanks John.

-Anand

jjl at pobox.com (John J. Lee) wrote in message news:<87znfu5sqm.fsf at pobox.com>...
> [Anand: your newsreader is outputting double-spaced text, and seems to
> have failed to put your post in the right thread]
> 
> anandpillai <member29923 at dbforums.com> writes:
> > I see that we are talking about a kind of interactive authentication
> > here, since it looks like the certificate and key files need to be
> > supplied as arguments.
> 
> Not sure what you mean.
> 
> 
> > If you are requesting a SSL authorized document from a webserver
> > using a webbrowser all this happens kind of transparent right?
> 
> I guess you have to point the browser at your key / cert somehow, but
> yeah, I assume so.  Never used it, never read the relevant standards.
> 
> 
> > 1. client figures out that the protocol is HTTPS.
> >    (Most of the time the actual HTTPS url is masked
> >     by a HTTP one, which forwards the request to
> >     the secure server.)
> > 
> > 2. Client asks for the SSL certificate from the
> >     server.
> 
> No, you're making the same mistake I did a while back (see a recent
> c.l.py thread and one of those bugs I referred to): the thing urllib
> implements is *client* authentication, not *server* authentication!
> The server wants to know that it's talking to the right client, not
> vice-versa.
> 
> If you're after server authentication, that's NOT implemented in
> either urllib or urllib2.  I think that would require changes to
> socketmodule.c to call the appropriate OpenSSL functions.  You'd also
> need to fetch and check certificate revocation lists.
> 
> To fend off the obvious questions before somebody asks them: Yes,
> HTTPS URLs can still be opened, but you end up talking securely to a
> server whose identity you don't know (which isn't so very different
> from the reality of the usual HTTPS web experience, I suppose).  Yes,
> the Python library docs are certainly broken and should be fixed!
> 
> Back to client authentication...
> 
> [...]
> >    I was wondering if it could be as transparent as this.
> > 
> >    Psuedocode follows.
> > 
> >     pwdmgr = HTTPSPasswordManager()
> >     pwdmgr.add_password('realm', 'http://lockedurl', 'user', 'pass')
> >      auth = HTTPSBasicAuthHandler(pwdmgr)
> > 
> >      urllib2.install_opener( auth, ... )
> > 
> >      urllib2.urlopen('http://lockedurl/lockeddoc')
> 
> Yeah, I guess it would be better to have it work like that, instead of
> having to have a new handler for every site as with the patch I posted
> (though I guess you're unlikely to have to auth like this for many
> sites?).  I don't know if HTTPPasswordManager's assumptions are useful
> for this purpose (eg., I've no idea if there's any concept of 'realm'
> involved here), but if not it's easy enough for HTTPSClientAuthHandler
> to ask an HTTPSPasswordManager passed to it as a constructor arg, just
> like AbstractBasicAuthHandler (in HTTPSClientAuthHandler.https_open).
> 
> But let's make sure urllib is working first!
> 
> BTW, a correction to that earlier patch:
> 
> -    class HTTPSClientAuthHandler(AbstractHTTPHandler):
> +    class HTTPSClientAuthHandler(HTTPSHandler):
> 
> 
> (so that HTTPSClientAuthHandler takes precedence over HTTPSHandler in
> build_opener).
> 
> 
> > I can figure that the current situation is far from it.
> > For example,  does your code take care of the scenario
> > discussed above?
> 
> Not sure if by 'the scenario' you're referring to your explanation of
> the events that occur during authentication, or the example code you
> give above.  If the former, you don't need the 401 / 407 stuff that is
> required for Basic and Digest HTTP auth., because this is taking place
> at the socket level (assuming urllib gets it right!).  If the latter,
> yes, my patch doesn't do that.
> 
> 
> > I will test out the urllib code anyway and also read
> > some documentation on SSL on the web. :-)
> [...]
> 
> SSL and X509.  Good idea -- I certainly don't have a clue about it :-)
> 
> 
> John