SSL security authorization?

[John J. Lee]

[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