And anyway I'm not in agreement that if people are going to use
outbound encryption -- if they are going to simply call a PHP function
-- they need to understand how to update their local CA bundle. I
would think that, the majority of the time, users are either [a]
loading a provided "PHP binding" (.PHP file) for a public API or [b]
copying-and-pasting boilerplate code from API documentation and, just
speaking realistically, you should not expect them to know what's
going on under the hood. You can have a relatively good understanding
of HTTP (without the S) and when your service says "now you must use
encryption" there shouldn't be a big learning curve on the user side.
I'm totally in agreement with everything you've said. There is no "learning
curve." The only thing required for a secure transfer in this case is the
knowledge that:
(1) You need a CA to verify that the other party is who they say they are
(2) As such, you have to tell PHP about the CA file(s) you want it to use.
There is nothing confusing or difficult about setting a single php.ini
value "openssl.cafile = C:\path\to\cacert.pem"
But there is something very wrong with allowing users to do this without
peer verification by default:
file_get_contents('http://yourbankinginstitution.com');
The whole point of the recently accepted RFC and the new RFC on TLS
security is to eliminate the need for users to understand TLS to use these
features. There is no disagreement here and I'm not sure what you're
arguing here.
I have added the curl ca cert file option
As of the recently merged RFC there now exist both openssl.cafile and
openssl.capath (for hashed certificate directories). I was unaware of the
curl php.ini option and perhaps you were unaware of the new openssl ini
options?
Either way, it might make sense to have a single universal option instead.
There is still time to change/implement something like this for 5.6.
Thoughts?
I have added the curl ca cert file option
As of the recently merged RFC there now exist both openssl.cafile and
openssl.capath (for hashed certificate directories). I was unaware of the
curl php.ini option and perhaps you were unaware of the new openssl ini
options?Either way, it might make sense to have a single universal option instead.
There is still time to change/implement something like this for 5.6.
Thoughts?
As we discussed on IRC, I think it makes sense to merge the curl CA
file ini setting and use the openssl one. Maybe alias them so we won't
have BC issues (curl is in place since quite some time already).
About bundling the CA file with the windows release (we agreed not to
release them with the src, good this way), we still have time to
evaluate it. We will not bundle it for the next releases, including
first betas. If testers are complaining too much, it will be a sign
that we may have to bundle it. As the support part won't scale well
with all our end users on Windows.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
I'm totally in agreement with everything you've said. There is no "learning
curve." The only thing required for a secure transfer in this case is the
knowledge that:
(1) You need a CA to verify that the other party is who they say they are
(2) As such, you have to tell PHP about the CA file(s) you want it to use.
No.
The other "only thing" required for a secure transfer on Windows, if
you do not ship a working Windows installer, is that the user
[] have permission to manage the server's PHP installation
For emphasis: we are talking about the PHP developer.
I don't know how you can assume that the PHP dev who is authoring --
let alone simply rolling out -- a WordPress plug-in can perform this
step. Perhaps "learning curve" is the wrong term. How about "newly
required server privileges"?
Of course, they may be able to specify a PEM in their home directory.
Which means they have to change the code they are rolling out to add
the extra arguments. Which means that third-party code can no longer
be updated automatically.
There is nothing confusing or difficult about setting a single php.ini
value "openssl.cafile = C:\path\to\cacert.pem"
The whole point of the recently accepted RFC and the new RFC on TLS
security is to eliminate the need for users to understand TLS to use these
features.
The intent of turning on peer verification by default is to enforce
better security at the possible (in fact, previously documented) cost
of users having to understand, if not TLS itself, how to manage a CA
There is no disagreement here and I'm not sure what you're
arguing here.
On Mon, Feb 3, 2014 at 2:33 PM, Sanford Whiteman sandy@figureone.comwrote:
I'm totally in agreement with everything you've said. There is no
"learning
curve." The only thing required for a secure transfer in this case is the
knowledge that:(1) You need a CA to verify that the other party is who they say they are
(2) As such, you have to tell PHP about the CA file(s) you want it to
use.No.
I'm still completely befuddled. No one is arguing against ease-of use here.
Have you read the relevant RFCs? Please just take sixty seconds to at least
read this one part then come back and tell me I'm making it more
difficult for the average user to make secure transfers.
https://wiki.php.net/rfc/improved-tls-defaults#tldr_definitive_progress
I'm clearly trying to simplify secure https:// usage as much as possible.
What may or may not be tenable is the management of a custom CA file.
Distribution has its own issues and deserves as much consideration as
userland ease-of use. Instantly discounting those is a myopic approach. You
can't just instantly rule out that bundling a file might not be feasible.
No one is arguing against ease-of use here.
PHP users may now need to have write access to PHP.INI in order to not
get logs filled with security warnings, for the same code that
previously did not issue a warning. Or else they need to change all
outbound stream code, which in many cases isn't even theirs to safely
change.
This isn't ease-of-use. This is hardening security at the cost of
ease-of-use for some users. We must call it what it is.
Have you read the relevant RFCs?
I was the one who told you the Peer Verification RFC would break the
official WPI package (break == E_WARNING without end) and nobody cared
then. Now it's like a minor after-the-fact surprise after the RFC was
accepted.
This thread itself actually surprised me: I honestly didn't think you
cared about the issue at all. Figured the next we'd hear about it
would be in WONTFIXes on the bug tracker with directions to download
the CA bundle. I'm psyched I got the earlier heads-up on Internals,
and I don't worry about our servers because I have full control. Other
users don't and you will upset them. I am not saying these changes to
PHP are not advisable. They are! But how can you be "befuddled" when
you started a thread that notes that Windows users may need to have
sysadmin privileges -- else they will be constantly reminded that they
don't?
Please just take sixty seconds to at least read this one part then
come back and tell me I'm making it more difficult for the average
user to make secure transfers.
We will have made it easier for PHP users to either
[a] make secure transfers
or
[b] fill up their logs with warnings
The "average" user will fit into [a] per recent PHP statistics (at
least on the production side) so yeah, the "average" user will see a
major benefit.
How many users need to fit into [b] for you to acknowledge that this
rollout is going to be less than fully successful -- not a failure,
just not an unqualified success -- unless we take those users
seriously?
Instantly discounting those is a myopic approach. You can't just
instantly rule out that bundling a file might not be feasible.
It's fine to not bundle a file.
It's not fine to pretend that warnings will not be endlessly spewed on
Windows without a file.
It's not fine to suppress these warnings on Windows but not elsewhere.
-- S.
PHP users may now need to have write access to PHP.INI in
order to not get logs filled with security warnings, for thesame
code that previously did not issue a warning.
To avoid any confusion, note that the above statement is incorrect.
ini_set('openssl.cafile', 'C:\omg\this\is\too\hard.pem');
Source:
https://github.com/php/php-src/blob/PHP-5.6/ext/openssl/openssl.c#L1078
Manual entry on where INI directives may be changed:
http://www.php.net/manual/en/configuration.changes.modes.php
Or else they need to change all outbound stream
code, which in many cases isn't even theirs to safely change.
Then I'm using a garbage library and need to migrate immediately. The
maintainers don't know the first thing about security and they're putting
all of my data at risk. Thank goodness for these warning to alert me that
I'm doing something seriously wrong. I definitely didn't know that and I
don't want to be left holding the bag when I compromise all my users'
personal and sensitive information. Now I can fix it.
This is the entire point of warnings: to tell you you're doing something
wrong. Suggesting this is somehow harmful is seriously negligent. Let's not
pretend like the doctor setting a cast on a broken arm is the problem; the
broken arm is the problem.
ini_set('openssl.cafile', 'C:\omg\this\is\too\hard.pem');
OK, users simply add ini_set on all their pages. Why bother playacting
about this being worth discussing if you actually think it's
\just\so\easy\for\any\user? Why start this thread?
Or else they need to change all outbound stream
code, which in many cases isn't even theirs to safely change.
Then I'm using a garbage library and need to migrate immediately.
Yay! Let's tell people to "migrate immediately" from a WordPress
plugin but also act like we didn't affect their PHP user experience in
any way. Not even some negative impact for a net good, nope, all
positive impact.
I think you need to get more experience with the range of third-party
code that doesn't turn on verify_peer. And frankly it is PHP's fault
that most code doesn't do so, since PHP was insecure by default and
never threw an error in the past. Heaping blame on library authors is
absurd. If someone is writing to the Twitter API, they might not know
anything about CAs, figuring, not entirely unreasonably, that making
an outbound connection to https://api.twitter.com would be as verified
as it would be from a browser. Furthermore, even if they did have an
inkling that their connections weren't best-practices secureit is
ridiculously cumbersome to try to bundle a PEM with a lightweight CMS
plugin.
This is the entire point of warnings: to tell you you're doing
something wrong. Suggesting this is somehow harmful is seriously
negligent. Let's not pretend like the doctor setting a cast on a
broken arm is the problem; the broken arm is the problem.
Of course it's harmful to spew warnings into a log when you damn well
you could have worked harder (i.e. bundling the trusted CA bundle) to
not have that happen.
-- S.
it is ridiculously cumbersome to try to bundle a PEM with a
lightweight CMS plugin.
Moreover, it may not even be possible to bundle a PEM with plugin
code, depending on the distribution/packaging rules for whether your
code can be in the CMS's official "app store."
-- S.
Hi,
On 3 February 2014 22:17, Sanford Whiteman
swhitemanlistens-software@cypressintegrated.com wrote:
I think you need to get more experience with the range of third-party
code that doesn't turn on verify_peer. And frankly it is PHP's fault
that most code doesn't do so, since PHP was insecure by default and
never threw an error in the past. Heaping blame on library authors is
absurd. If someone is writing to the Twitter API, they might not know
I'm sorry, but this is simply outrageous. It is a programmer's
responsibility to code securely. It's not absurd, it's reality. If you
can't program securely, you shouldn't be programming. This is not some
fantasy world where I should pity programmers for their ignorance.
It's a world were security flaws can cost companies money, endanger
user's privacy and THEIR money, where even minor mistakes can have
devastating consequences to privacy and compliance with national and
international laws. I fire programmers who can't learn secure coding,
but thankfully that's almost unheard of ;). A little training goes a
long way. My next favourite excuse is the one where Man-In-The-Middle
attacks are rare theoretical occurances and so why bother - a belief
in utter defiance of how the internet works. I bet the NSA gets a real
chuckle out of that one. What's the next excuse? Right, it's all PHP's
fault.
Your blaming of PHP is significantly misplaced. It is not solely
responsible for programmer malpractice. There are programmers out
there, right this moment, with code all across Github doing one very
unusual thing. They are deliberately disabling peer verification in
cURL where it is enabled by default. They WILL do the same with PHP
streams/sockets. The buck stops at the programmer's feet and that's
it. All PHP can do is promote and encourage best practices, it can
never enforce them.
Paddy
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative
I'm sorry, but this is simply outrageous. It is a programmer's
responsibility to code securely. It's not absurd, it's reality. If
you can't program securely, you shouldn't be programming.
No, the reality is that (most) PHP users (most of whom are consuming
someone else's code to some degree) assume that making an SSL
connection means "secure."
It is absurd to claim otherwise. In fact, we are agreeing that that
assumption should always have been correct by changing the default
behavior in PHP!
How can you possibly "blame" users and "fix" the behavior at the same
time?
Your blaming of PHP is significantly misplaced.
No, it is not.
If it were, this patch would not exist, for it has ALWAYS been
possible to create a peer-verified outbound connection from PHP.
You cannot at once place blame only on the developer and make a core
change so the language is "the way it should always have been."
-- S.
Hi,
On 3 February 2014 23:56, Sanford Whiteman
swhitemanlistens-software@cypressintegrated.com wrote:
I'm sorry, but this is simply outrageous. It is a programmer's
responsibility to code securely. It's not absurd, it's reality. If
you can't program securely, you shouldn't be programming.No, the reality is that (most) PHP users (most of whom are consuming
someone else's code to some degree) assume that making an SSL
connection means "secure."It is absurd to claim otherwise. In fact, we are agreeing that that
assumption should always have been correct by changing the default
behavior in PHP!How can you possibly "blame" users and "fix" the behavior at the same
time?
Hello. I am a programmer. Sorry, but oopsie, that script I wrote to
retrieve client data from our remote office? Well, I sort of forgot to
configure SSL correctly and, well, somebody dumped a whole list of
client names, emails, social security numbers and other personally
identifiable information onto a file dump site. I'm really really
sorry. It's all PHP's fault.
FIRED! FIRED! FIRED! :P
I blame programmers for security problems because it's their fault.
Anyone who can't take personal responsibility needs to grow up and own
up. Programmers aren't, at least in a professional capacity, children
anymore. This whole attitude of avoiding responsibility by pointing
fingers at anything else is the one thing that drives security people
demented.
Your blaming of PHP is significantly misplaced.
No, it is not.
We'll have to agree to disagree about who gets blamed when hackers strike.
If it were, this patch would not exist, for it has ALWAYS been
possible to create a peer-verified outbound connection from PHP.You cannot at once place blame only on the developer and make a core
change so the language is "the way it should always have been."
You missed the cURL part of my last email, I presume...
--
Pádraic Brady
http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team
Zend Framework PHP-FIG Representative
I blame programmers for security problems because it's their fault.
So do I understand you correctly that you are against this patch?
Because as I said I can see your viewpoint as long as you aren't
admitting that the language's insecure defaults have anything to do
with user behavior.
You missed the cURL part of my last email, I presume...
Not at all, but we aren't changing cURL defaults so it's irrelevant.
-- Sandy
Your blaming of PHP is significantly misplaced. It is not solely
responsible for programmer malpractice. There are programmers out
there, right this moment, with code all across Github doing one very
unusual thing. They are deliberately disabling peer verification in
cURL where it is enabled by default. They WILL do the same with PHP
streams/sockets. The buck stops at the programmer's feet and that's
it. All PHP can do is promote and encourage best practices, it can
never enforce them.
So you don't agree with this patch? In that case I agree, you are
being fully consistent and this standpoint is quite convincing. If we
don't touch the language, we can affix blame solely to the user.
However my argument assumed the patch was accepted into the language.
In that context it is foolish to say the language bears no
responsibility while at the same time making language changes so it
behaves "the way it should have been."
There are programmers out there, right this moment, with code all
across Github doing one very unusual thing. They are deliberately
disabling peer verification in cURL where it is enabled by default
These aren't the programmers who are affected by the changing of
defaults. They are fully culpable.
-- S.
Anyway, I think we get off-topic with discussions of those who
knowingly write insecure code, e.g. manually turning off secure
options to save effort.
Also think it is unnecessary in the context of a related language
change to discuss whether users writing insecure code due to
ignorance of PHP's defaults is no excuse, a partial excuse, or a full
excuse.
All that matters is that the default options were being trusted in the
real world by real -- by job description, if not competence --
developers. If it needs to be fixed, we should fix it, but with no
extra grudges in the implementation.
When we bear a grudge against our own users for "forcing" a language
change we leave the doors open for punishing them with the
implementation of that change. This is my main argument with Daniel:
either we accept that we are breaking people's setups with a change
regardless of their ultimate responsibility for that change, or we
don't make the change.
Stating that it's dirt-simple to make such a change is a way of
punishing a subset of users who aren't any worse developers than the
rest, and perhaps most unfortunately it targets a minority of users
who already get the short end of the stick when it comes to
extensions, etc., and now will be told that their code is less secure
than their *nix counterparts' code -- even though the *nix side is
going to get more secure without doing a whit of work. I guess the
laissez-faire attitude about Windows users is what sticks in my craw,
like they get a bizarre hybrid of respect and disrespect with this
patch.
-- S.
PHP users may now need to have write access to PHP.INI in
order to not get logs filled with security warnings, for thesame
code that previously did not issue a warning.To avoid any confusion, note that the above statement is incorrect.
ini_set('openssl.cafile', 'C:\omg\this\is\too\hard.pem');
By the way, I'm not totally sure we should make this setting a user
setting but system, like it is now for curl.
That being said, I would also suggest to stay on focus, this
discussion is getting off base, @sanford.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
That being said, I would also suggest to stay on focus, this
discussion is getting off base, @sanford.
Whatever, nothing else to add. Peer verification was voted in for 5.6
knowing that Windows users would be SOL unless they availed themselves
of a CA bundle (and openssl.cafile as INI_ALL). If they can't figure
out how to get it they probably shouldn't be developing, it's true.
On Tue, Feb 4, 2014 at 6:58 AM, Sanford Whiteman
swhitemanlistens-software@cypressintegrated.com wrote:
That being said, I would also suggest to stay on focus, this
discussion is getting off base, @sanford.Whatever, nothing else to add. Peer verification was voted in for 5.6
knowing that Windows users would be SOL unless they availed themselves
of a CA bundle (and openssl.cafile as INI_ALL). If they can't figure
out how to get it they probably shouldn't be developing, it's true.
As I said earlier in this thread we have enough time to evaluate the
right solution.
We will try not to bundle the CA file until the 1st beta and see what
kind of issues testers are experiencing.
In any case, a script to fetch it from the curl site should be
provided, in the source and binaries releases. This script should be
documented in the PHP manual and in the upgrading guide (same for this
RFC in general).
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Pierre Joye wrote:
In any case, a script to fetch it from the curl site should be
provided, in the source and binaries releases. This script should be
documented in the PHP manual and in the upgrading guide (same for this
RFC in general).
At the risk of being shouted at as off topic ... This is not the only
configuration data that may need managing externally to PHP builds. The tz data
is similarly updated outside the PHP build cycles. People are hitting time being
wrong more than having a problem with an out of date CA file ... and windows
versions of the data tend to lag behind. Security is not the only thing that is
reliant nowadays on third party data?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Pierre Joye wrote:
In any case, a script to fetch it from the curl site should be
provided, in the source and binaries releases. This script should be
documented in the PHP manual and in the upgrading guide (same for this
RFC in general).At the risk of being shouted at as off topic ...
If you know it is off topic (just like the constant rants about
notices and other "issues" you run into with legacy codes), why do you
post it in the 1st place?
That being said, I think we all know your views on these topics.
This is not the only
configuration data that may need managing externally to PHP builds. The tz
data is similarly updated outside the PHP build cycles. People are hitting
time being wrong more than having a problem with an out of date CA file ...
and windows versions of the data tend to lag behind.
Security is not the
only thing that is reliant nowadays on third party data?
We bundle the TZ data and it is used on all supported platforms. So
no, no platform lags behind other. Some distributions may patch the
date extension to use the system TZ but then it is none of our
business.
Cheers,
Pierre
@pierrejoye | http://www.libgd.org
Pierre Joye wrote:
Security is not the
only thing that is reliant nowadays on third party data?
We bundle the TZ data and it is used on all supported platforms. So
no, no platform lags behind other. Some distributions may patch the
date extension to use the system TZ but then it is none of our
business.
But that is the whole point here ... it's the same argument with CA file?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Pierre Joye wrote:
Security is not the
only thing that is reliant nowadays on third party data?
We bundle the TZ data and it is used on all supported platforms. So
no, no platform lags behind other. Some distributions may patch the
date extension to use the system TZ but then it is none of our
business.But that is the whole point here ... it's the same argument with CA file?
If someone distributes a patched PHP, it is none of our business.
And CA file on Windows is not the same issue as Windows do not have
system CA files compatible with OpenSSL. Implementing a backend using
windows keys store and SSL APIs would bring more issues and
incompatibilities (user lever) than asking users to set an ini
setting.
Pierre Joye wrote:
Pierre Joye wrote:
Security is not the
only thing that is reliant nowadays on third party data?
We bundle the TZ data and it is used on all supported platforms. So
no, no platform lags behind other. Some distributions may patch the
date extension to use the system TZ but then it is none of our
business.But that is the whole point here ... it's the same argument with CA file?
If someone distributes a patched PHP, it is none of our business.
And CA file on Windows is not the same issue as Windows do not have
system CA files compatible with OpenSSL. Implementing a backend using
windows keys store and SSL APIs would bring more issues and
incompatibilities (user lever) than asking users to set an ini
setting.
OK that is making sense. The only reason that the tz data sprang to mind is a
similar situation. Up until now windows has also had it's own timezone data
management, so was not compatible with tz, but it seems from information being
received that newer versions of windows are now using the tz data itself as it
was their data which was lagging behind the real world. Linux distributions do
update their tz data, but windows installs of PHP can't take advantage of the
same update path? Just like the CA files.
It's PHP distributing the 'patched' windows builds here?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
OK that is making sense. The only reason that the tz data sprang to mind
is a similar situation. Up until now windows has also had it's own timezone
data management,
This statement and the rest of your mail are wrong.
Again Php TZ data always have been built in, be on windows or other
platforms.
It's PHP distributing the 'patched' windows builds here?
No and no need to either.
Pierre Joye wrote:
OK that is making sense. The only reason that the tz data sprang to mind is a
similar situation. Up until now windows has also had it's own timezone data
management,This statement and the rest of your mail are wrong.
Again Php TZ data always have been built in, be on windows or other platforms.
It's PHP distributing the 'patched' windows builds here?
No and no need to either.
Now I'm just not sure if this is a matter of translating English?
It is a simple fact that the Linux distributions handle all of the material they
support via the package management. Many of them update PHP with minor version
updates when things like a new tz version comes out or some other library gets
updated. They patch the PHP distribution to suit their needs and keep things up
to date. Which nowadays is the right way of working.
Windows does not have the same update path when it comes to PHP and the like, so
it needs a third party to provide up to date information. Either the user
downloads a recent windows build from PHP or some other source. Or an
alternative would be if there was some script mechanism to update CA files or tz
data rather than having to a full reinstall? PHP does not up-issue simply
because a new tz database is available, so in order to keep time up to date it
would be nice to address that problem. IF Microsoft are now using the tz
database directly then it may be possible to use that update via windows update.
I understand why the same does not apply to the CA files ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
It is a simple fact that the Linux distributions handle all of the material
they support via the package management.
Yes, still none of our business.
Many of them update PHP with minor
version updates when things like a new tz version comes out
Yes, if they use the bundled TZ data, but then it is updated via the
extension update not the whole php.
or some other
library gets updated. They patch the PHP distribution to suit their needs
and keep things up to date. Which nowadays is the right way of working.
Still none of our business.
Windows does not have the same update path when it comes to PHP and the
like, so it needs a third party to provide up to date information.
TZ is bundled and updated on a regular basis. Updating PHP updates the
TZ data. It however does not help to update it while keeping the same
php version running. We can't do much about it.
Or
an alternative would be if there was some script mechanism to update CA
files or tz data rather than having to a full reinstall?
The CA data is a single file and we will provide a script to update
it. Add it to a cron and you are done. We can't do that for the TZ
data due to technical reasons. We could find a way but it is not worth
the effort, one can always update PHP to x.y.z+1.
PHP does not
up-issue simply because a new tz database is available, so in order to keep
time up to date it would be nice to address that problem. IF Microsoft are
now using the tz database directly
Microsoft has nothing to do with that. They update the Windows TZ
database, which is not used by PHP and there is no plan to use it.
Even if we would use it, it would bring a lot of issues due to cross
platform compatibility.
Cheers,
--
Pierre
@pierrejoye | http://www.libgd.org
Hey Pierre, re: the script to download the trusted CA bundle, how do
you propose to make that connection secure the first time?
Not being facetious. I was convinced (albeit suddenly) by Padraic's
argument that all fault for insecure remote transfers lies with the
developer as long as secure options exist. How do we avoid being that
same kind of developer? Neither plain-text download nor unverified TLS
should be used for the trusted CA root list. The ability to tamper
with that download would be catastrophic.
If we can't ship the CA bundle and can't ship even the CA cert for the
site we choose to deliver the bundle, I think it's better to give
people the URL and tell them to use a browser (which will perform
verification).
I was poking around and noticed that Mono's CLI for fetching the CA
bundle (in this case Mozilla's) uses a plain http:// URL. I find this
to be rather bizarre under the circumstances.
[http://linux.die.net/man/1/mozroots]
-- S.
On Thu, Feb 6, 2014 at 7:13 AM, Sanford Whiteman <
swhitemanlistens-software@cypressintegrated.com> wrote:
Hey Pierre, re: the script to download the trusted CA bundle, how do
you propose to make that connection secure the first time?Not being facetious. I was convinced (albeit suddenly) by Padraic's
argument that all fault for insecure remote transfers lies with the
developer as long as secure options exist. How do we avoid being that
same kind of developer? Neither plain-text download nor unverified TLS
should be used for the trusted CA root list. The ability to tamper
with that download would be catastrophic.If we can't ship the CA bundle and can't ship even the CA cert for the
site we choose to deliver the bundle, I think it's better to give
people the URL and tell them to use a browser (which will perform
verification).I was poking around and noticed that Mono's CLI for fetching the CA
bundle (in this case Mozilla's) uses a plain http:// URL. I find this
to be rather bizarre under the circumstances.
[http://linux.die.net/man/1/mozroots]-- S.
--
What Pierre is/was proposing is that we include the CA file to the windows
binary distribution, and we also include a script, which can
generate/download the same CA file, so if you don't trust us to sneak
something to the CA file, you can see for yourself, and also, when the
Windows team does the packaging, they would use the same script (executed
by a php installation already properly configured for ssl) to create the CA
file to be included to the binary release.
So this would serve more of a transparency purpose, than to provide a way
to the php installs without a CA file to get one(as you mentioned, that
would be a chicken/egg problem).
At least this is my understanding of the proposal (and if you remember, I'm
on the side of not shipping a CA file at all, but educating our users
where/how to get one).
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
I'm totally in agreement with everything you've said. There is no "learning
curve." The only thing required for a secure transfer in this case is the
knowledge that:
(1) You need a CA to verify that the other party is who they say they are
(2) As such, you have to tell PHP about the CA file(s) you want it to use.
No.
The other "only thing" required for a secure transfer on Windows, if
you do not ship a working Windows installer, is that the user
(3) have permission to manage the server's PHP installation
For emphasis: we are talking about the PHP developer.
I don't know how you can assume that the PHP dev who is authoring --
let alone simply rolling out -- a WordPress plug-in can perform this
step. Perhaps "learning curve" is the wrong term. How about "newly
required server privileges"?
Of course, they may be able to specify a PEM in their home directory.
Which means they have to change the code they are rolling out to add
the extra arguments. Which means that third-party code can no longer
be updated automatically.
There is nothing confusing or difficult about setting a single php.ini
value "openssl.cafile = C:\path\to\cacert.pem"
The whole point of the recently accepted RFC and the new RFC on TLS
security is to eliminate the need for users to understand TLS to use these
features.
The intent of turning on peer verification by default is to enforce
better security at the possible (in fact, previously documented) cost
of users having to understand, if not TLS itself, how to manage a
trusted CA bundle, and having permission to do so.
Please, let's not pretend that these measures are "eliminating" any
burdens previously placed on the user -- except the burden that
follows accidentally compromising your system due to forged
certificates, of course!
-- S.