On 23 January 2014 08:37, Stephen J. Turnbull wrote:
>
> I don't know what the right answer is, but this needs careful
> discussion and amelioration, not just "you're broken, so take the
> consequences!"
>
Absolutely. =)
With that said, having a great big button to turn the change off
(e.g. envir
On 24 January 2014 03:06, Stephen J. Turnbull wrote:
> Are you kidding? These *aren't* the apps that I care about breaking,
> and I know that the PHBs won't pay attention to what I say about
> fixing their sites and cert chains (believe me, I've tried, and the
> answer is as Paul Moore says: the
On Jan 23, 2014, at 10:09 PM, Donald Stufft wrote:
>
> On Jan 23, 2014, at 10:06 PM, Stephen J. Turnbull wrote:
>
>> Wes Turner writes:
But if it's only the already security-conscious developers and
managers who go WTF?, and other environments don't do this by default,
I'd cons
On Jan 23, 2014, at 10:06 PM, Stephen J. Turnbull wrote:
> Wes Turner writes:
>>> But if it's only the already security-conscious developers and
>>> managers who go WTF?, and other environments don't do this by default,
>>> I'd consider that a "dangerous curve, slow down" sign.
>>
>> Mitigation
Wes Turner writes:
> > But if it's only the already security-conscious developers and
> > managers who go WTF?, and other environments don't do this by default,
> > I'd consider that a "dangerous curve, slow down" sign.
>
> Mitigations:
>
> **Packaging**
>
> * Upgrade setuptools (dist
On 01/22/2014 05:16 AM, M.-A. Lemburg wrote:
On 22.01.2014 13:43, Jesse Noller wrote:
Donald is perfectly right: today, it's trivial to MITM an application
that relies off of the current behavior; this is bad news bears for
users and developers as it means they need domain knowledge to secure
On 01/22/2014 04:15 AM, Donald Stufft wrote:
As I’ve said multiple times, I think it’s fine to send it through the
deprecation process which is still pretty long and gives people
a good chunk of time to update.
Agreed.
--
~Ethan~
___
Python-Dev mail
> But if it's only the already security-conscious developers and
> managers who go WTF?, and other environments don't do this by default,
> I'd consider that a "dangerous curve, slow down" sign.
Mitigations:
**Packaging**
* Upgrade setuptools (distribute, zc.buildout)
* Avoid easy_install, p
On 2014-01-22 9:33 AM, Donald Stufft wrote:
> For everything but pip, you’d add it to your OS cert store. Pip doesn’t
> use that so you’d have to use the —cert config.
> What if I don't want that self-signed cert to be trusted by all users on
the system?
Specify a client cert and an appropriate C
On Thu, 23 Jan 2014 06:02:18 +
Kristján Valur Jónsson wrote:
>
> If not already possible, I suggest that we allow the use of a certificate
> validation callback
> (it isn't possible for 2.7, I just hacked in one yesterday to allow me to
> ignore out-date-failure for certificates.)
> Using t
On Thu, 23 Jan 2014 01:45:15 -0500
Scott Dial wrote:
>
> Anecdotally, I already know of a system at work that is using HTTPS
> purely for encryption, because the authentication is done in-band. So, a
> self-signed cert was wholly sufficient. The management tools use a
> RESTful interface over HTT
On 23 January 2014 22:41, "Martin v. Löwis" wrote:
> Am 23.01.14 07:45, schrieb Scott Dial:
>> Anecdotally, I already know of a system at work that is using HTTPS
>> purely for encryption, because the authentication is done in-band. So, a
>> self-signed cert was wholly sufficient. The management t
Am 23.01.14 07:45, schrieb Scott Dial:
> Anecdotally, I already know of a system at work that is using HTTPS
> purely for encryption, because the authentication is done in-band. So, a
> self-signed cert was wholly sufficient. The management tools use a
> RESTful interface over HTTPS for control, bu
Donald Stufft writes:
> As an additional side note, anecdotal evidence and what not, but
> *every* time I bring this up somewhere I get at least one reply
> that looks similar to
> https://twitter.com/ojiidotch/status/425986619879866368
Hey, wait a cotton-picking minute!
Are you telling me t
Cory Benfield writes:
> I'm overwhelmingly, dramatically +1 on this. There's no good
> architectural reason to not use the built-in certificate chains by
> default. I'd like to be in favour of backporting this change to earlier
> Python versions as well, but it feels just a bit too aggressive.
On 2014-01-22 9:33 AM, Donald Stufft wrote:
> For everything but pip, you’d add it to your OS cert store. Pip doesn’t
> use that so you’d have to use the —cert config.
What if I don't want that self-signed cert to be trusted by all users on
the system? What if I don't have administrative rights? H
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Nick Coghlan
> Sent: Wednesday, January 22, 2014 19:45
> To: Paul Moore
> Cc: Python-Dev
> Subject: Re: [Python-Dev] Enable Hostname and Certifi
> While the normal deprecation process should suffice, that still means Python
> 3.6 (2017-ish) is the earliest feasible target for new default settings.
Could a CERT_NOVERIFY no-op be added now?
(no-op because it would just be more explicit about the default
behavior anyway) [1]
> Such a propos
On 22.01.2014 23:20, Nick Coghlan wrote:
> However, now we have access to the system cert stores on all major
> platforms, I *do* think it's a good idea to eventually change the
> default settings to include host verification.
Somebody has revise the situation on OSX for Python 3.5 and possible
cr
On 23 Jan 2014 07:48, "Donald Stufft" wrote:
>
> Never mind. If someone else cares they can propose it. I withdraw.
That's unfortunate, but understandable - we already have a lot to deal with
just trying to get even the software distribution infrastructure to a
"secure by default" status.
Howeve
On Wed, Jan 22, 2014, at 01:48 PM, Donald Stufft wrote:
> Never mind. If someone else cares they can propose it. I withdraw.
I'm sorry to see this thread went down hill so quickly. I think we can
all agree than not validating certs by default is bad and that it should
change "soon". It's only a
On Wed, Jan 22, 2014 at 3:48 PM, Donald Stufft wrote:
> Never mind. If someone else cares they can propose it. I withdraw.
>
I'll throw writing a PEP for 3.5 to do this following the deprecation
policy on my todo list so 3.4 fixing can move on. I needed to brush up
on my ReST anyway.
Never mind. If someone else cares they can propose it. I withdraw.
> On Jan 22, 2014, at 4:29 PM, Brett Cannon wrote:
>
>
>
>
>> On Wed, Jan 22, 2014 at 3:56 PM, Benjamin Peterson
>> wrote:
>>
>>
>> On Wed, Jan 22, 2014, at 12:25 PM, Nick Coghlan wrote:
>> > On 23 Jan 2014 00:39, "Benjam
On Wed, Jan 22, 2014 at 3:56 PM, Benjamin Peterson wrote:
>
>
> On Wed, Jan 22, 2014, at 12:25 PM, Nick Coghlan wrote:
> > On 23 Jan 2014 00:39, "Benjamin Peterson" wrote:
> > > Speaking of requests, I think another way to address this issue would
> be
> > > import a requests-like APIs into the s
On Wed, Jan 22, 2014, at 12:25 PM, Nick Coghlan wrote:
> On 23 Jan 2014 00:39, "Benjamin Peterson" wrote:
> > Speaking of requests, I think another way to address this issue would be
> > import a requests-like APIs into the stdlib (something which should
> > happen anyway) and make that verify c
On 23 Jan 2014 00:39, "Benjamin Peterson" wrote:
>
> On Wed, Jan 22, 2014, at 04:15 AM, Donald Stufft wrote:
> >
> > On Jan 22, 2014, at 6:58 AM, Nick Coghlan wrote:
> >
> > > On 22 January 2014 21:36, Donald Stufft wrote:
> > >> On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg wrote:
> > >>> The cha
On 1/22/2014 9:25 AM, Donald Stufft wrote:
Awesome, It looks like I’ll be writing a PEP to handle this, I wasn’t
sure if it needed one or not.
Definitely. I think the transition from insecure by default to secure by
default is somewhat comparable to the transition from ascii by default
to un
If I could summarize this discussion (please correct me if I am wrong):
1. Status Quo
All existing versions of Python are unsecure by default
because by not doing SSL hostname verification,
libraries which wrap sockets with SSLContext
allow SSL MITM (man-in-the-middle) with no warning
On Wed, 22 Jan 2014 13:50:37 -0500
Donald Stufft wrote:
>
> Ironically this is the exact reason why validation should happen by default :]
I think most of us would agree that a new client API should do
validation by default (with an easy way to opt out). So let's
concentrate on the question of w
On Jan 22, 2014, at 1:46 PM, Brian Curtin wrote:
> On Wed, Jan 22, 2014 at 12:10 PM, John Yeuk Hon Wong
> wrote:
>> On 1/22/14 8:16 AM, Nick Coghlan wrote:
>>>
>>> Which is exactly the way most non-web-specialists working inside the
>>> comfort of corporate and academic firewalls will react to
On Wed, Jan 22, 2014 at 12:10 PM, John Yeuk Hon Wong
wrote:
> On 1/22/14 8:16 AM, Nick Coghlan wrote:
>>
>> Which is exactly the way most non-web-specialists working inside the
>> comfort of corporate and academic firewalls will react to a change that
>> breaks their access to internal application
On 1/22/14 8:16 AM, Nick Coghlan wrote:
Which is exactly the way most non-web-specialists working inside the
comfort of corporate and academic firewalls will react to a change
that breaks their access to internal applications, where self-signed
certs and improperly configured internal CAs are e
On Wed, 22 Jan 2014 08:12:06 -0700
Eric Snow wrote:
> On Jan 22, 2014 6:17 AM, "M.-A. Lemburg" wrote:
> > Using an environment switch the extra checks could even be enabled
> > without any code changes.
>
> When Donald brought this up it sounded good. It still does. This is
> similar to what w
On 22 January 2014 10:30, Donald Stufft wrote:
> I would like to propose that a backwards incompatible change be
> made to Python to make verification of hostname and certificate
> chain the default instead of requiring it to be opt in.
I'm overwhelmingly, dramatically +1 on this. There's no good
Donald Stufft stufft.io> writes:
>
> I would like to propose that a backwards incompatible change be
> made to Python to make verification of hostname and certificate
> chain the default instead of requiring it to be opt in.
I'm overwhelmingly, dramatically +1 on this. There's no good
architect
On Wed, Jan 22, 2014, at 04:02 AM, Donald Stufft wrote:
>
> On Jan 22, 2014, at 6:45 AM, Nick Coghlan wrote:
>
> > On 22 January 2014 21:21, Paul Moore wrote:
> >> On 22 January 2014 10:30, Donald Stufft wrote:
> >>> Python 3.4 has made great strides in making it easier for applications
> >>>
On Jan 22, 2014 6:17 AM, "M.-A. Lemburg" wrote:
> Using an environment switch the extra checks could even be enabled
> without any code changes.
When Donald brought this up it sounded good. It still does. This is
similar to what we did for hash randomization.
-eric
On Jan 22, 2014, at 10:05 AM, Antoine Pitrou wrote:
> On Wed, 22 Jan 2014 15:33:21 +0100
> Christian Heimes wrote:
>>
>> About two months ago (maybe three) I proposed to deprecated implicit SSL
>> context, unverified certs and unverified hostnames all together. But I
>> was voted down. Donald
On Wed, 22 Jan 2014 15:33:21 +0100
Christian Heimes wrote:
>
> About two months ago (maybe three) I proposed to deprecated implicit SSL
> context, unverified certs and unverified hostnames all together. But I
> was voted down. Donald made a similar attempt half an year ago, too.
So why are you t
On 22.01.2014 15:36, Donald Stufft wrote:
> Last time I tried the reasoning was that Python couldn’t ship root certs
> and we couldn’t get to the OS certs everywhere. Thanks to you this
> is fixed now, so “once more unto the breach”.
The Windows situation is still not perfect, though. I'd love to
On Wed, Jan 22, 2014, at 04:15 AM, Donald Stufft wrote:
>
> On Jan 22, 2014, at 6:58 AM, Nick Coghlan wrote:
>
> > On 22 January 2014 21:36, Donald Stufft wrote:
> >> On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg wrote:
> >>> The change would also disable all services using self-signed
> >>> cert
On Jan 22, 2014, at 9:33 AM, Christian Heimes wrote:
> On 22.01.2014 15:12, Jesse Noller wrote:
>> And no one reads it. I can't count the number of times I've gotten called
>> into a managers office when they find out python doesn't do cert validation
>> by default (and in 2, it's not been tri
On 22.01.2014 15:12, Jesse Noller wrote:
> And no one reads it. I can't count the number of times I've gotten called
> into a managers office when they find out python doesn't do cert validation
> by default (and in 2, it's not been trivial) and gotten told to fix it, or we
> move off of python.
On Jan 22, 2014, at 9:28 AM, Paul Moore wrote:
> On 22 January 2014 13:29, Christian Heimes wrote:
>> Side note:
>> Users can simple add self-signed certs to OpenSSL's cert store and get
>> validation for free. It's possible to do that with an environment
>> variable, too. But I recommend again
On 22 January 2014 13:29, Christian Heimes wrote:
> Side note:
> Users can simple add self-signed certs to OpenSSL's cert store and get
> validation for free. It's possible to do that with an environment
> variable, too. But I recommend against the environment variable because
> you may overwrite
On Jan 22, 2014, at 9:19 AM, Paul Moore wrote:
> On 22 January 2014 13:55, Donald Stufft wrote:
>>
>> As an additional side note, anecdotal evidence and what not, but
>> *every* time I bring this up somewhere I get at least one reply that
>> looks similar to https://twitter.com/ojiidotch/statu
On 22 January 2014 13:55, Donald Stufft wrote:
>
> As an additional side note, anecdotal evidence and what not, but
> *every* time I bring this up somewhere I get at least one reply that
> looks similar to https://twitter.com/ojiidotch/status/425986619879866368
Surprise that Python doesn't verify
On Wed, 22 Jan 2014 15:13:00 +0100
Christian Heimes wrote:
> On 22.01.2014 13:43, Jesse Noller wrote:
> > I have to concur with Donald here - in the case of security, especially
> > language security which directly impacts the implicit security of
> > downstream applications, I should not have t
On Thu, Jan 23, 2014 at 1:08 AM, Jesse Noller wrote:
>> Now, maybe it wouldn't be a problem if the fix is an environment
>> variable, but imagine a thousand-computer deployment and you have to
>> tweak the environment on all of them. Feel like doing that just
>> because the newest Python needs it?
On 22.01.2014 13:43, Jesse Noller wrote:
> I have to concur with Donald here - in the case of security, especially
> language security which directly impacts the implicit security of downstream
> applications, I should not have to opt in to the most secure defaults.
>
> Yes; this potentially bre
> On Jan 22, 2014, at 8:03 AM, Christian Heimes wrote:
>
>> On 22.01.2014 14:55, Donald Stufft wrote:
>> As an additional side note, anecdotal evidence and what not, but
>> *every* time I bring this up somewhere I get at least one reply
>> that looks similar to
>> https://twitter.com/ojiidotch
On 22.01.2014 14:24, Nick Coghlan wrote:
> On 22 January 2014 23:19, Antoine Pitrou wrote:
>> On Wed, 22 Jan 2014 05:30:40 -0500
>> Donald Stufft wrote:
>>> I would like to propose that a backwards incompatible change be
>>> made to Python to make verification of hostname and certificate
>>> chai
> On Jan 22, 2014, at 6:58 AM, Chris Angelico wrote:
>
>> On Wed, Jan 22, 2014 at 11:15 PM, Donald Stufft wrote:
>> Do you really think those people would be making the same complaints
>> if they could restore the previous behavior with a simple boolean flag
>> delivered either via environment
On 22.01.2014 14:55, Donald Stufft wrote:
> As an additional side note, anecdotal evidence and what not, but
> *every* time I bring this up somewhere I get at least one reply
> that looks similar to
> https://twitter.com/ojiidotch/status/425986619879866368
Yeah :(
The ssl module documentation h
On Jan 22, 2014, at 8:29 AM, Christian Heimes wrote:
> On 22.01.2014 12:45, Nick Coghlan wrote:
>> We also have to account for the fact that an awful lot of Python
>> applications are corporate ones relying on perimeter defence for
>> security, or private CAs, or just self-signed certificates th
On 22.01.2014 12:45, Nick Coghlan wrote:
> We also have to account for the fact that an awful lot of Python
> applications are corporate ones relying on perimeter defence for
> security, or private CAs, or just self-signed certificates that their
> users have already accepted. There are limits to t
On 22 January 2014 23:19, Antoine Pitrou wrote:
> On Wed, 22 Jan 2014 05:30:40 -0500
> Donald Stufft wrote:
>> I would like to propose that a backwards incompatible change be
>> made to Python to make verification of hostname and certificate
>> chain the default instead of requiring it to be opt
On Wed, 22 Jan 2014 05:30:40 -0500
Donald Stufft wrote:
> I would like to propose that a backwards incompatible change be
> made to Python to make verification of hostname and certificate
> chain the default instead of requiring it to be opt in.
>
> Python 3.4 has made great strides in making it
On 22 January 2014 22:15, Donald Stufft wrote:
>
> On Jan 22, 2014, at 6:58 AM, Nick Coghlan wrote:
>>
>> The kinds of decisions that an application like a web browser or a
>> package installer can make aren't necessarily available to a runtime.
>> We had to be cautious even with the initial hash
On 22.01.2014 13:43, Jesse Noller wrote:
>> Well, it's not really a security issue, since the security features
>> are present in Python 3.4. It's just that the user has to enable them.
>
> I have to concur with Donald here - in the case of security, especially
> language security which directly
On Wed, Jan 22, 2014 at 11:15 PM, Donald Stufft wrote:
> Do you really think those people would be making the same complaints
> if they could restore the previous behavior with a simple boolean flag
> delivered either via environment variable or in their own code?
You assume that it's easy to twe
> On Jan 22, 2014, at 5:30 AM, "M.-A. Lemburg" wrote:
>
>> On 22.01.2014 11:56, Donald Stufft wrote:
>>
>>> On Jan 22, 2014, at 5:51 AM, M.-A. Lemburg wrote:
>>>
On 22.01.2014 11:30, Donald Stufft wrote:
I would like to propose that a backwards incompatible change be made to
On 22 January 2014 12:02, Donald Stufft wrote:
>> We also have to account for the fact that an awful lot of Python
>> applications are corporate ones relying on perimeter defence for
>> security, or private CAs, or just self-signed certificates that their
>> users have already accepted. There are
On Jan 22, 2014, at 6:58 AM, Nick Coghlan wrote:
> On 22 January 2014 21:36, Donald Stufft wrote:
>> On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg wrote:
>>> The change would also disable all services using self-signed
>>> certificates which are very common in internal networks and
>>> for ad-hoc
On 22 January 2014 11:29, Donald Stufft wrote:
>> 1. To be "like the browser" we'd need to use the OS certificate store,
>> which isn't the case on Windows at the moment (managing those
>> certificate bundle files is most definitely *not* "like the browser" -
>> I'd have no idea how to add a self-
On Jan 22, 2014, at 7:03 AM, Paul Moore wrote:
> On 22 January 2014 11:29, Donald Stufft wrote:
>>> 1. To be "like the browser" we'd need to use the OS certificate store,
>>> which isn't the case on Windows at the moment (managing those
>>> certificate bundle files is most definitely *not* "lik
On Jan 22, 2014, at 6:45 AM, Nick Coghlan wrote:
> On 22 January 2014 21:21, Paul Moore wrote:
>> On 22 January 2014 10:30, Donald Stufft wrote:
>>> Python 3.4 has made great strides in making it easier for applications
>>> to simply turn on these settings, however many people are not aware
>>
On 22 January 2014 21:36, Donald Stufft wrote:
> On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg wrote:
>> The change would also disable all services using self-signed
>> certificates which are very common in internal networks and
>> for ad-hoc setups. Many routers and other devices use self-signed
>>
On 22.01.2014 12:36, Donald Stufft wrote:
>
> On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg wrote:
>> The change would also disable all services using self-signed
>> certificates which are very common in internal networks and
>> for ad-hoc setups. Many routers and other devices use self-signed
>> ce
On 22 January 2014 21:21, Paul Moore wrote:
> On 22 January 2014 10:30, Donald Stufft wrote:
>> Python 3.4 has made great strides in making it easier for applications
>> to simply turn on these settings, however many people are not aware
>> at all that they need to opt into this. Most assume that
On Jan 22, 2014, at 6:21 AM, Paul Moore wrote:
> 2. Your proposal is that because some application authors have not
> opted in yet, we should penalise the end users of those applications
> by stopping them being able to use unverified https? And don't forget,
> applications that haven't opted in
On Jan 22, 2014, at 6:30 AM, M.-A. Lemburg wrote:
> On 22.01.2014 11:56, Donald Stufft wrote:
>>
>> On Jan 22, 2014, at 5:51 AM, M.-A. Lemburg wrote:
>>
>>> On 22.01.2014 11:30, Donald Stufft wrote:
I would like to propose that a backwards incompatible change be made to
Python to m
On 22.01.2014 11:56, Donald Stufft wrote:
>
> On Jan 22, 2014, at 5:51 AM, M.-A. Lemburg wrote:
>
>> On 22.01.2014 11:30, Donald Stufft wrote:
>>> I would like to propose that a backwards incompatible change be made to
>>> Python to make
>>> verification of hostname and certificate chain the de
On Jan 22, 2014, at 6:21 AM, Paul Moore wrote:
> On 22 January 2014 10:30, Donald Stufft wrote:
>> Python 3.4 has made great strides in making it easier for applications
>> to simply turn on these settings, however many people are not aware
>> at all that they need to opt into this. Most assume
On 22 January 2014 10:30, Donald Stufft wrote:
> Python 3.4 has made great strides in making it easier for applications
> to simply turn on these settings, however many people are not aware
> at all that they need to opt into this. Most assume that it will operate
> similarly to their browser, cur
On Jan 22, 2014, at 5:51 AM, M.-A. Lemburg wrote:
> On 22.01.2014 11:30, Donald Stufft wrote:
>> I would like to propose that a backwards incompatible change be made to
>> Python to make
>> verification of hostname and certificate chain the default instead of
>> requiring it to be opt
>> in.
>
On 22.01.2014 11:30, Donald Stufft wrote:
> I would like to propose that a backwards incompatible change be made to
> Python to make
> verification of hostname and certificate chain the default instead of
> requiring it to be opt
> in.
>
> Python 3.4 has made great strides in making it easier fo
77 matches
Mail list logo
