Zend Framework

HTTPS in Zend_Http_Client is to be considered insecure

Details

Description

Zend_Http_Client (to more specific: it's only available adapter Zend_Http_Client_Adapter_Socket) does neither verify server certificates nor does it verify hostnames. Zend_Http_Client_Adapter_Curl behaves correct, but is not in trunk.

Best regards,
Thomas Gelf

Issue Links

This issue depends on:
ZF-3616 Create Zend_Http_Client_Adapter_Curl Major Resolved
ZF-2946 Zend_Http_Client_Adapter_Socket be able to set stream context options Major Resolved

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Benjamin Eberlei added a comment -

Fixed with ZF-3616, inclusion of cURL Adapter into trunk, released in 1.8

Show
Benjamin Eberlei added a comment - Fixed with ZF-3616, inclusion of cURL Adapter into trunk, released in 1.8
Hide
Permalink
Thomas Gelf added a comment -

This is great news! I've been using your adapter for a while, the fact that it will be provided with ZF will however make things easier

Anyways, this doesn't solve the issue for me: Zend_Http_Client is still to be considered insecure with HTTPS and still prone to MITM attacks. This is also true for all Service-Components based on Zend_Http_Clients. The fact that there finally IS a secure connection adapter does neither fix the default one (Socket), nor does it tell coders to NOT use the default one for HTTPS unless fixed nor does it fix other components based on Zend_Http_Client.

Show
Thomas Gelf added a comment - This is great news! I've been using your adapter for a while, the fact that it will be provided with ZF will however make things easier Anyways, this doesn't solve the issue for me: Zend_Http_Client is still to be considered insecure with HTTPS and still prone to MITM attacks. This is also true for all Service-Components based on Zend_Http_Clients. The fact that there finally IS a secure connection adapter does neither fix the default one (Socket), nor does it tell coders to NOT use the default one for HTTPS unless fixed nor does it fix other components based on Zend_Http_Client.
Hide
Permalink
Shahar Evron added a comment -

Depends on being able to set context parameters on the stream. Work in progress on that.

Show
Shahar Evron added a comment - Depends on being able to set context parameters on the stream. Work in progress on that.
Hide
Permalink
Shahar Evron added a comment -

Now that the setStreamContext() and getStreamContext() methods have been added (in trunk, CS-17009), you should be able to force peer validation easily.

We can't set this behavior to be the default one, because of BC issues. I also suspect most people will not want this because it makes development and testing harder.

Thanks for reporting!

Show
Shahar Evron added a comment - Now that the setStreamContext() and getStreamContext() methods have been added (in trunk, CS-17009), you should be able to force peer validation easily. We can't set this behavior to be the default one, because of BC issues. I also suspect most people will not want this because it makes development and testing harder. Thanks for reporting!
Hide
Permalink
Thomas Gelf added a comment -

That's great news, thank you!

Let me add some thoughts regarding default settings. First, this is what
I posted last autumn to ZF's mailinglist:

> Unfortunately switching validation on per default is not an option as
> it would break currently working applications. I would suggest to change
> this with ZF 2.0 - as other libs / languages I know (CURL, Java, C# etc)
> are doing so out of the box. And in my believes this is the only correct
> way of using HTTPS. If someone wants to do insecure things he is free to
> do so, but he has to explicitly switch checks off.

(see http://www.nabble.com/Validating-SSL-server-certs---using-CA-certs-p20225319.html for full post)

I don't know which Zend_Service_Whatever-Classes are based on HTTPS
(a quick grep showed Amazon_Ec2, Delicious, ReCaptcha), probably all of
them are using Zend_Http_Client - with insecure defaults. And I'm pretty
sure others will follow.

Therefore I strongly suggest changing default settings with ZF 2.0. Many
developers just don't realize that self-signed certificates lead HTTPS ad
absurdum - and also not verifying signed ones does. If someone insists on
using useless certificates he can do so. But he needs to be made aware of
doing something REALLY bad (and shall be forced into explicitely allowing
this in his own code).

What is the best way to add a note assuring this doesn't will be forgotten?
Open a seperate ticket against "Next Major Release"?

Best regards,
Thomas Gelf

Show
Thomas Gelf added a comment - That's great news, thank you! Let me add some thoughts regarding default settings. First, this is what I posted last autumn to ZF's mailinglist: > Unfortunately switching validation on per default is not an option as > it would break currently working applications. I would suggest to change > this with ZF 2.0 - as other libs / languages I know (CURL, Java, C# etc) > are doing so out of the box. And in my believes this is the only correct > way of using HTTPS. If someone wants to do insecure things he is free to > do so, but he has to explicitly switch checks off. (see http://www.nabble.com/Validating-SSL-server-certs---using-CA-certs-p20225319.html for full post) I don't know which Zend_Service_Whatever-Classes are based on HTTPS (a quick grep showed Amazon_Ec2, Delicious, ReCaptcha), probably all of them are using Zend_Http_Client - with insecure defaults. And I'm pretty sure others will follow. Therefore I strongly suggest changing default settings with ZF 2.0. Many developers just don't realize that self-signed certificates lead HTTPS ad absurdum - and also not verifying signed ones does. If someone insists on using useless certificates he can do so. But he needs to be made aware of doing something REALLY bad (and shall be forced into explicitely allowing this in his own code). What is the best way to add a note assuring this doesn't will be forgotten? Open a seperate ticket against "Next Major Release"? Best regards, Thomas Gelf
Hide
Permalink
Ralph Schindler added a comment -

Postponing issue until 2.0 when we can change the defaults in the socket adapter to be more like that of the curl adapter: validating all certificates by default.

Show
Ralph Schindler added a comment - Postponing issue until 2.0 when we can change the defaults in the socket adapter to be more like that of the curl adapter: validating all certificates by default.

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Zend Framework. Try JIRA - bug tracking software for your team.