Re: Python Learning Environment
Krister Svanlund
<vijay...@gmail.com> wrote:
> Hi,
> My Linux box is ubuntu system. I want to create a development environment on
> my system for python programing language. I got to see there are two
> versions of python language
> 1. python 2.5.6
> 2. python 3.1.2
> To find out what version i look in to my "/usr/bin" folder. There are many
> entries for python command
> - python
> - python2
> - python2.5
> - python2.6
> - python3
> - python3.1
> what does this mean? I am able to run run my first program with all these
> command. should i remove all these and have the latest one? I am confused
> about these finding. Is this okay to have these all?
>
> Regards,
> Vijay Shanker Dubey
>
python is symlinked to one of the 2.5, 2.6 or 3.1... most probably
2.6. The python2 is symlink to one of 2.5 or 2.6 and python3 is
symlinked to python3.1. It's a clever way to be able to specify what
version is needed for a script.
Krister Svanlund
<vijay...@gmail.com> wrote:
> Yes you are right about symlink thing.
> So what should I do for a clever developer environment?
> Should I change that python link to python3 or python3.1?
>
> Regards,
> Vijay Shanker Dubey
>
It all depends on what you want to do. I would say that you shouldn't
change your python link at all, if you want to run a python script
using 3.1 just call the script using python3 as an interpreter.
John Nagle
I've found what looks like a security hole. The "ssl" module will
validate the certificate chain, but it doesn't check that the certificate
is valid for the domain.
Here's the basic code:
sk = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock = ssl.wrap_socket(sk, ca_certs=certfile,
cert_reqs=ssl.CERT_REQUIRED)
sock.connect((domain,443))
cert = sock.getpeercert()
print('SSL cert for "%s":' % (domain,))
for fieldname in cert :
print(' %s = %s' % (fieldname, cert[fieldname]))
Note that I'm sending a CA cert list and am specifying CERT_REQUIRED,
so I should get a proper cert check.
Now let's try a host that presents the wrong SSL cert. Try, in
a browser,
https://www.countrysidecabinetry.com
You'll get an error. But the "ssl" module is happy with this cert:
SSL cert for "www.countrysidecabinetry.com":
notAfter = Dec 8 23:30:48 2010 GMT
subject = ((('serialNumber', u'E5gMXaDjnqfFPID2KNdLTVNEE6PjtqOr'),),
(('countryName', u'US'),), (('organizationName', u'customla
serengravings.com'),), (('organizationalUnitName', u'GT57631608'),),
(('organizationalUnitName', u'See www.rapidssl.com/resources/cp
s (c)09'),), (('organizationalUnitName', u'Domain Control Validated -
RapidSSL(R)'),), (('commonName', u'customlaserengravings.com')
,))
Note that the cert is for "customlaserengravings.com", but is being
presented by "countrysidecabinetry.com". Fail.
When I try this with M2Crypto, I get an SSL.Checker.WrongHost exception.
That's what should happen.
John Nagle
exa...@twistedmatrix.com
It's a bit debatable. There probably should be a way to make this
happen, but it's far from clear that it's the only correct behavior.
And, as it turns out, there is a way to make it happen - call
getpeercert() and perform the check yourself. ;)
Here's some related discussion for an equivalent API in a different
module:
http://twistedmatrix.com/trac/ticket/4023
At the very least, the documentation for this should be very clear about
what is and is not being checked.
Jean-Paul
John Nagle
> On 04:51 pm, na...@animats.com wrote:
>> I'm converting some code from M2Crypto to the new "ssl" module, and
>> I've found what looks like a security hole. The "ssl" module will
>> validate the certificate chain, but it doesn't check that the certificate
>> is valid for the domain.
>>
> It's a bit debatable. There probably should be a way to make this
> happen, but it's far from clear that it's the only correct behavior.
> And, as it turns out, there is a way to make it happen - call
> getpeercert() and perform the check yourself. ;)
"Checking it yourself" is non-trivial. The checking code has to
understand DNS wildcards and additional domains in cert extensions.
The SSL module doesn't seem to let you read all the cert extensions,
(in particular, you don't get "certificatePolicies", so you can't
tell if a cert is an "extended validation" cert) but it looks like
you do get the subjectAltName fields present in the extensions, like this:
subjectAltName = (('DNS', 'www.chapinfurniture.com'),
('DNS', 'chapinfurniture.com')))
So it's at least possible to check. Almost.
(DNS wildcards look like this: "*.example.com". It's also possible
to have "*.*.example.com". However, no DNS wildcard cert should cover
more than one second-level domain (huge security hole if you allow that)
and no extended validation cert should have a wildcard.)
There may also be issues with internationalized domain names.
It's very bad for the "ssl" module to both ignore this check and
not have that mentioned prominently in the documentation. This is
a security-critical function. Somewhere, there's a Python program that
can be exploited due to this bug.
Here's a comparison of what M2Crypto and the SSL module return, for
"verisign.com", which uses most cert features.
Trying domain "www.verisign.com"
Host: www.verisign.com Port: 443
Info from "M2Crypto: module:
Cipher = DHE-RSA-AES256-SHA
Subject info: [('CN', 'verisign.com'),
('OU', 'production Security Services '),
('O', 'VeriSign, Inc.'),
('streetAddress', '487 East Middlefield Road'),
('L', 'Mountain View'),
('ST', 'California'),
('postalCode', '94043'),
('C', 'US'),
('serialNumber', '2497886'),
('2.5.4.15', 'V1.0, Clause 5.(b)'),
('jurisdictionOfIncorporationStateOrProvinceName', 'Delaware'),
('jurisdictionOfIncorporationCountryName', 'US')]
Certificate has 10 extensions.
Extension #0: subjectAltName = DNS:verisign.com, DNS:www.verisign.com,
DNS:verisign.mobi, DNS:www.verisign.mobi, DNS:verisign.eu, DN
S:www.verisign.eu
Extension #1: basicConstraints = CA:FALSE
Extension #2: subjectKeyIdentifier =
0F:75:C5:F7:06:11:CE:74:FC:5F:DA:B6:2A:53:CE:39:1C:D6:7D:19
Extension #3: keyUsage = Digital Signature, Key Encipherment
Extension #4: crlDistributionPoints =
URI:http://EVIntl-crl.verisign.com/EVIntl2006.crl
Extension #5: certificatePolicies = Policy: 2.16.840.1.113733.1.7.23.6
CPS: https://www.verisign.com/rpa
Extension #6: extendedKeyUsage = TLS Web Server Authentication, TLS Web Client
Authentication, Netscape Server Gated Crypto
Extension #7: authorityKeyIdentifier =
keyid:4E:43:C8:1D:76:EF:37:53:7A:4F:F2:58:6F:94:F3:38:E2:D5:BD:DF
Extension #8: authorityInfoAccess = OCSP - URI:http://EVIntl-ocsp.verisign.com
CA Issuers - URI:http://EVIntl-aia.verisign.com/EVIntl2006.cer
Extension #9: UNDEF = None
Info from "ssl" module:
SSL cert for "www.verisign.com":
notAfter = Apr 2 23:59:59 2012 GMT
subject = ((('1.3.6.1.4.1.311.60.2.1.3', u'US'),),
(('1.3.6.1.4.1.311.60.2.1.2', u'Delaware'),),
(('2.5.4.15', u'V1.0, Clause 5.(b)'),),
(('serialNumber', u'2497886'),),
(('countryName', u'US'),),
(('postalCode', u'94043'),),
(('stateOrProvinceName', u'California'),),
(('localityName', u'Mountain View'),),
(('streetAddress', u'487 East Middlefield Road'),),
(('organizationName', u'VeriSign, Inc.'),),
(('organizationalUnitName', u'production Security Services '),),
(('commonName', u'verisign.com'),))
John Nagle
geremy condra
> http://mail.python.org/mailman/listinfo/python-list
>
I talked about this in my pycon lighting talk- it's actually been
known for some time, and in fact there's some comments in
Zope core that mention this problem being a motivation for
rewriting SSL support from scratch. IIRC (I seem to recall
this, but I seem to have lost my test harness for it) it also
impacts higher level libraries like urllib, but I would verify that
before taking it as gospel. Several of the other members of
python-crypto would know more about it than I.
As a side note, it also impacts IronPython.
Geremy Condra
exa...@twistedmatrix.com
>exa...@twistedmatrix.com wrote:
>>On 04:51 pm, na...@animats.com wrote:
>>> I'm converting some code from M2Crypto to the new "ssl" module,
>>>and
>>>I've found what looks like a security hole. The "ssl" module will
>>>validate the certificate chain, but it doesn't check that the
>>>certificate
>>>is valid for the domain.
>...
>>It's a bit debatable. There probably should be a way to make this
>>happen, but it's far from clear that it's the only correct behavior.
>>And, as it turns out, there is a way to make it happen - call
>>getpeercert() and perform the check yourself. ;)
>
> "Checking it yourself" is non-trivial.
Yes. It'd be nice to having something in the stdlib which accepted a
hostname and a certificate and told you if they line up or not.
>The SSL module doesn't seem to let you read all the cert extensions,
Yes. That sucks. It was argued about on python-dev and ultimately the
people writing the code didn't want to expose everything. I don't
remember the exact argument for that position.
> It's very bad for the "ssl" module to both ignore this check and
>not have that mentioned prominently in the documentation.
I agree. As I said, I think the behavior should be well documented.
Jean-Paul
John Nagle
What a mess.
The cause of the problem seems to be someone named "Bill Janssen (janssen)"
See "http://bugs.python.org/issue1589". He shouted down attempts to put in
this check, apparently because he saw use cases for a backdoor. He
claimed he would change the documentation, but did not do so, leaving
the backdoor enabled.
Without host name checking, you lose all "man in the middle" protection
in SSL.
Jannsen wrote:
"Nope. Hostname verification was never a good idea -- the "hostname" is
just a vague notion, at best -- lots of hostnames can map to one or more
IP addresses of the server."
This is an weak objection for the SSL module, since the SSL "connect"
function can take a domain name, not an IP address. You can pass an
IP address to "connect", but if you pass a domain name, it should
be validated against the certificate. Also, with TLS, name validation
is supposed to work even for multiple domains on the same IP address.
(But see "http://en.wikipedia.org/wiki/Server_Name_Indication", which
says that it works in most current browsers, but not Python.)
Heikki Toivonen (heikki), author of M2Crypto, wrote:
"I would definitely recommend providing as strict as possible hostname
verification in the stdlib, but provide application developers a way to
override that."
Hekki put a warning about this on his blog at
"http://www.heikkitoivonen.net/blog/2008/10/14/ssl-in-python-26/".
All major browsers make this check. Most Python users will expect the
SSL module to do the checks a browser does. If the user went to the
trouble to provide a certificate authority file, and specified CERT_REQUIRED,
they presumably want their connections fully validated.
But Jannsen closed the issue anyway. Looks like a "developer in denial"
situation.
The sample code suggested for a user-level check at
http://bugs.python.org/msg58508
does not handle valid domain wildcards, which makes it unusable in practice.
It's non-trivial to do this in accordance with the spec.
Here's an example of code written by someone who wasn't aware of this bug.
"http://www.muchtooscrawled.com/2010/03/https-certificate-verification-in-python-with-urllib2/"
It's not clear if this hole made it into Twisted, or the Python
BitTorrent client.
Who's reviewing the SSL module for security? Is anyone checking for backdoors?
John Nagle