5 ms·

SSL and PHP Streams, Part 1

36 points by DaveRandom 12y ago

thegeomaster 12y ago
It by default doesn't try to verify the certificate of the peer it's connecting to? Isn't that the whole point of introducing TLS support? Pardon me if I'm missing something, but that sounds like a horrible design decision, and anyone who tries to use TLS streams without reading the documentation is fooled into a false sense of security.
- viraptor 12y ago
  Yeah, I was surprised by that part until: "We must also specify the expected peer name on the presented certificate with the `CN_match` option, it will not be inferred from the URL and if it is not specified, the name on the certificate will not be validated." WTF? Who ever got the idea that this is something that can ever hit production?
  - RobAley 12y ago
    Again the article is out of date, it's now parsed from the URL if you don't specify a CN_match (which you can still do if you need to).
    - DaveRandom 12y ago
      Not before 5.6 (where CN_match is actually deprecated in favour of peer_name)
    - viraptor 12y ago
      This doesn't matter now. People don't (and sometimes cannot) upgrade quickly. Also, documentation for the latest version still says peer_verify defaults to false and CN_match doesn't mention being computed automatically. Effectively if you write any code you're not going to deploy yourself, you have to specify the CN_match and verify_peer. Others will not know about the limitations, so this function is messed up until after 5.5 is EOLed. Designing APIs is hard and bad defaults can hurt for many major versions after they're changed.
    - chc 12y ago
      It is? Which of the versions of PHP linked from the homepage of PHP.net do this? I didn't think any of them did.
- RobAley 12y ago
  The article is somewhat out of date, the default is now to verify (though you can turn it off if you need to). A lot is changing with PHP, and people aren't keeping up.
  - johnnyfaehell 12y ago
    I love how this article was written today and is already out of date.
    - DaveRandom 12y ago
      I did quite clearly state, this information applies to PHP versions before 5.6 (which means that in practice, people need to be doing this for at least the next two years until 5.6 is widely adopted)... The next article will cover the changes in 5.6 and why you don't need to set those ctx opts any more (and a few more you might want to set instead)
  - viraptor 12y ago
    > the default is now to verify You mean in the version that's not properly released or anywhere close to production ready? 5.5 still defaults to not verifying according to the documentation.
PSeitz 12y ago
Innovative Titles - You are doing it wrong.
iopq 12y ago
PHP - Part 1: You Are Doing It Wrong
johnnyfaehell 12y ago
Personally if I was getting data from HTTP in PHP the last thing I would ever do is use file_get_contents. Just because you can doesn't mean you should. It's generally advised to set allow_url_include to off which would make this code not work. Also if you're mention curl in your technical article about code you should ask yourself why your code isn't using the curl integration in the language you're using. Putting a "You are doing it wrong" in your title is just asking for people to point out everything that is wrong with it.
- DaveRandom 12y ago
  cURL has it's problems - one of them being a different kind of hateful API, another being the fact that you still need to actually configure it properly, which means you have to be approximately competent. A major element of the 5.6 changes (documented in an article not yet written, but should be by early next week) is to protect Jimmy the junior dev from himself - chances are that an inexperienced dev, given the choice between a one-liner and several lines with a bunch of scary-looking options, is going to pick the former. I'm not advocating it, just stating it.
- TazeTSchnitzel 12y ago
  >Personally if I was getting data from HTTP in PHP the last thing I would ever do is use file_get_contents. Just because you can doesn't mean you should. Why not? file_get_contents makes things much simpler, and there's nothing really wrong with it. Fetching a JSON file is simple, for example: $file = file_get_contents("http://example.com/some.json"); if ($file === FALSE) { die("Failed to get JSON file"); } $data = json_decode($file); if ($data === NULL) { die("Failed to decode JSON"); } echo htmlspecialchars($data->foo->bar); To be honest, I think cURL is unnecessary in most cases. PHP's HTTP streams do a better job without relying on an additional extension (HTTP streams are in the PHP core, while cURL must be built separately and often installed separately), and the HTTP stream context options with their string key names are much nicer than the dreaded CURLOPT_* constants.
  - johnnyfaehell 12y ago
    Why not? 1) The name of the function is file_get_contents, however you're not getting a file. It just annoys me, it reads wrong. stream_get_contents is better but I still wouldn't go reaching for streams for HTTP requests. 2) It provides you with a lack of control. 3) It's pretty sloppy, to do anything like POST requests with bodies you have to do hacky stuff. I wouldn't be writing my own curl call request either I would use a library such as Guzzle.
vegancap 12y ago
Ha no way, I'm sure I had a job interview with these guys. Cool to see some Manchester based tech on front-page HN.
revelation 12y ago
Wow, that is terrible. I'm not even talking about the shitty defaults, but look at the code to make it "secure". String-based programming and all of the underlying OpenSSL crap just spills up to the API. No one should be using that, if only because with the magic strings everywhere it is not guaranteed to blow up when there are breaking changes.
- TazeTSchnitzel 12y ago
  >String-based programming Are we talking about the same language? This is PHP, not Tcl. >all of the underlying OpenSSL crap just spills up to the API. None of it does. I mean, there's an extension for OpenSSL, but that's not what's 'spilling up'. What's happening is there were poor defaults, so people have to change them. Luckily, PHP 5.6 fixes this. >No one should be using that, if only because with the magic strings everywhere it is not guaranteed to blow up when there are breaking changes. "Magic strings"? Are you seriously trying to compare using string names for keys to specify options (standard practise in many languages) with magic numbers?

36 points by DaveRandom 12y ago

It by default doesn't try to verify the certificate of the peer it's connecting to? Isn't that the whole point of introducing TLS support? Pardon me if I'm missing something, but that sounds like a horrible design decision, and anyone who tries to use TLS streams without reading the documentation is fooled into a false sense of security.

viraptor 12y ago
Yeah, I was surprised by that part until: "We must also specify the expected peer name on the presented certificate with the `CN_match` option, it will not be inferred from the URL and if it is not specified, the name on the certificate will not be validated." WTF? Who ever got the idea that this is something that can ever hit production?
- RobAley 12y ago
  Again the article is out of date, it's now parsed from the URL if you don't specify a CN_match (which you can still do if you need to).
  - DaveRandom 12y ago
    Not before 5.6 (where CN_match is actually deprecated in favour of peer_name)
  - viraptor 12y ago
    This doesn't matter now. People don't (and sometimes cannot) upgrade quickly. Also, documentation for the latest version still says peer_verify defaults to false and CN_match doesn't mention being computed automatically. Effectively if you write any code you're not going to deploy yourself, you have to specify the CN_match and verify_peer. Others will not know about the limitations, so this function is messed up until after 5.5 is EOLed. Designing APIs is hard and bad defaults can hurt for many major versions after they're changed.
  - chc 12y ago
    It is? Which of the versions of PHP linked from the homepage of PHP.net do this? I didn't think any of them did.
RobAley 12y ago
The article is somewhat out of date, the default is now to verify (though you can turn it off if you need to). A lot is changing with PHP, and people aren't keeping up.
- johnnyfaehell 12y ago
  I love how this article was written today and is already out of date.
  - DaveRandom 12y ago
    I did quite clearly state, this information applies to PHP versions before 5.6 (which means that in practice, people need to be doing this for at least the next two years until 5.6 is widely adopted)... The next article will cover the changes in 5.6 and why you don't need to set those ctx opts any more (and a few more you might want to set instead)
- viraptor 12y ago
  > the default is now to verify You mean in the version that's not properly released or anywhere close to production ready? 5.5 still defaults to not verifying according to the documentation.

PSeitz 12y ago

Innovative Titles - You are doing it wrong.

iopq 12y ago

PHP - Part 1: You Are Doing It Wrong

johnnyfaehell 12y ago

Personally if I was getting data from HTTP in PHP the last thing I would ever do is use file_get_contents. Just because you can doesn't mean you should. It's generally advised to set allow_url_include to off which would make this code not work. Also if you're mention curl in your technical article about code you should ask yourself why your code isn't using the curl integration in the language you're using. Putting a "You are doing it wrong" in your title is just asking for people to point out everything that is wrong with it.

DaveRandom 12y ago
cURL has it's problems - one of them being a different kind of hateful API, another being the fact that you still need to actually configure it properly, which means you have to be approximately competent. A major element of the 5.6 changes (documented in an article not yet written, but should be by early next week) is to protect Jimmy the junior dev from himself - chances are that an inexperienced dev, given the choice between a one-liner and several lines with a bunch of scary-looking options, is going to pick the former. I'm not advocating it, just stating it.
TazeTSchnitzel 12y ago
>Personally if I was getting data from HTTP in PHP the last thing I would ever do is use file_get_contents. Just because you can doesn't mean you should. Why not? file_get_contents makes things much simpler, and there's nothing really wrong with it. Fetching a JSON file is simple, for example: $file = file_get_contents("http://example.com/some.json"); if ($file === FALSE) { die("Failed to get JSON file"); } $data = json_decode($file); if ($data === NULL) { die("Failed to decode JSON"); } echo htmlspecialchars($data->foo->bar); To be honest, I think cURL is unnecessary in most cases. PHP's HTTP streams do a better job without relying on an additional extension (HTTP streams are in the PHP core, while cURL must be built separately and often installed separately), and the HTTP stream context options with their string key names are much nicer than the dreaded CURLOPT_* constants.
- johnnyfaehell 12y ago
  Why not? 1) The name of the function is file_get_contents, however you're not getting a file. It just annoys me, it reads wrong. stream_get_contents is better but I still wouldn't go reaching for streams for HTTP requests. 2) It provides you with a lack of control. 3) It's pretty sloppy, to do anything like POST requests with bodies you have to do hacky stuff. I wouldn't be writing my own curl call request either I would use a library such as Guzzle.

vegancap 12y ago

Ha no way, I'm sure I had a job interview with these guys. Cool to see some Manchester based tech on front-page HN.

revelation 12y ago

Wow, that is terrible. I'm not even talking about the shitty defaults, but look at the code to make it "secure". String-based programming and all of the underlying OpenSSL crap just spills up to the API. No one should be using that, if only because with the magic strings everywhere it is not guaranteed to blow up when there are breaking changes.

TazeTSchnitzel 12y ago
>String-based programming Are we talking about the same language? This is PHP, not Tcl. >all of the underlying OpenSSL crap just spills up to the API. None of it does. I mean, there's an extension for OpenSSL, but that's not what's 'spilling up'. What's happening is there were poor defaults, so people have to change them. Luckily, PHP 5.6 fixes this. >No one should be using that, if only because with the magic strings everywhere it is not guaranteed to blow up when there are breaking changes. "Magic strings"? Are you seriously trying to compare using string names for keys to specify options (standard practise in many languages) with magic numbers?