-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Security: Disallow anything but TLS 1.0+ #894
Comments
I pushed one commit which changed two urls to from http to https. Could you elaborate on how Drush should call I noticed that the following does not work with https - |
For cURL, this will allow any TLS version:
For wget, this may work, but I'm unsure whether it prevents use of TLSv1.1+:
|
As for git.drupal.org, would you mind emailing Rudy to let him know, with your example and output? If you can't, let me know so I can follow up with him. |
I would love a Pull Request for this issue, as I'm not 100% too familiar Line 803 in c98151c
|
I added --tlsv1 to the curl invocation. For wget, --secure-protocol=TLSv1 means that the server can choose any SSL type. At least thats how I read http://www.gnu.org/software/wget/manual/html_node/HTTPS-_0028SSL_002fTLS_0029-Options.html. When I try to use 1_1, and 1_2, I am seeing Note that Drush currently uses wget over curl when both are present on the CLI. We might want to change this. |
Maybe we should fetch with goutte. |
We have bash at our disposal. I'm not too keen on adding large dependencies for minor gains. |
Drupal.org switched from Edgecast to Fastly today, and
Running the wget command manually:
Invalid cert in action: https://updates.drupal.org/release-history/drupal/8.x |
If you look at one of those updates.drupal.org URLs in a web browser, you can examine the certificate and see that the name in the cert is not correct. |
Maybe the cert is correct, but wget does not interpret it correctly? c.f. https://docs.fastly.com/guides/ssl/why-do-i-see-ssl-certificate-errors-when-using-wget |
Drupal.org does not support https on updates.drupal.org. It was an accident of edgecast before, but not officially supported. We'll have it soon, but the api for updates.drupal.org is http only at the moment. |
--no-check-certificate does appear to happen to work at the moment (an accident of fastly?). Maybe it's better to use that than to go all the way back to http? |
Drupal core does not support HTTPS for updates requests, YMMV with any use of https://updates.drupal.org until there is official support in core. HTTPS is currently a best effort thing. That said, we are planning to get https enabled with a proper certificate for updates.d.o and ftp.d.o, but the discussion for adding https support started this morning, and I can't predict the timeline for that quite yet. |
So, in my testing, after wget fails, Drush tries again with:
This works for me. php 5.5.21. Maybe we can let this go for a while? |
@greg-1-anderson It does not work on PHP 5.6 because 5.6 valides the SSL Cert? Here is a Travis Build with 5.6 https://travis-ci.org/hechoendrupal/DrupalConsole/jobs/66205359 |
I understand that Drupal does not use https for updates.drupal.org, but I took David's proposal to mean that infra supports it. Even if we change this for drush6 and drush7 today, it will take a long time for folks to update their Drush. How Feasible is it for the Drupal Infra team to roll back the Fastly switch for the updates.drupal.org domain? That would fix everyone's woes immediately and then https support at Fastly could be added at a relaxed pace. |
hmm... Indeed HTTPS was not really 'supported' on updates, largely because its not used. (the percentage of https access is minuscule) We were unaware drush started using it and indeed the old versions are a problem. Rudy is sending the fastly conversation to me so I can look at where things stand. I'll update with how possible getting https working on fastly is and what we decide we can do. |
Hi! My solution. I created a ~/.wgetrc and I putted the following:
Now it is working for me. |
@weitzman We have a solution we are going to look at. The problem (as it always is), is usage stats and purging. Its why this is on fastly to begin with. |
Here's a much better workaround for the missing SSL cert on fastly. For Drush Make: https://gist.github.com/mikeyp/e517bf75611f69d702e3 For Drush pm-download: https://gist.github.com/greg-1-anderson/fb1dba054c35c46af644 It is still important to not just set-and-forget this (perhaps we should enhance the pm code to WARN on insecure connections, for future), but at least this way you only affect Drush, not all wget applications. |
Unofficial https support is back. We now have the following configuration to alleviate the pains of using drush's https:
I have a call with Fastly tomorrow to get things moving on https support with them, and we should have something free of this work around mid-late next week. |
Great! Thanks for the fast action! |
We now have a shared SAN wildcard cert on Fastly for updates (and ftp.drupal.org). EdgeCast is no longer fronting the updates traffic. |
Thanks @grigarr. If folks are interested, I can submit a patch for Drupal and packaging script to start using SSL for update XML and ftp site. Not urgent. |
Did vi really fix this? I see this running the latest of master branch (commit:ec8089f) Running drush download in debug
Manual testing:
|
This is working for me right now -- even after removing my cached updatexml files. I did notice, however, that after fetching the location for the release from updatexml via https, Drush goes ahead and uses whatever is specified in the XML file to download the actual file contents. This typically is 'http://ftp.drupal.org'. Manually testing a fetch from 'https://ftp.drupal.org' seemed to work just fine; perhaps we should swap in 'https' in place of 'http' here. |
Part of adding the certificate support to Fastly also means we can use https for ftp.drupal.org in addition to updates.drupal.org -- This support shouldn't go away, and is part of our longer term plan to force https on *.drupal.org |
@greg-1-anderson Did you test with PHP 5.6? Thats the one that had problems originally.I have not tested The packaging script is what needs to start pointing to https for ftp.drupal.org. No Drush changes needed there. |
I am still on php 5.5; have not tried 5.6. I suppose it's time to upgrade to 5.6 everywhere & not look back. (http://php.net/supported-versions.php) I added #1481 as a proposal; not sure if it helps enough to be valuable, though. |
My report ^^ was by using PHP 5.6. Have not tested with PHP 5.5 but I guess it works with that version. Soon time to leave PHP 5.5 :) |
I just upgraded to php 5.6, and still could not reproduce the problem above. I have to imagine that the problem is highly localized to the system that is failing; if pm-download did not work, I am sure that we would get a lot of reports about it. |
Thanks for your swift reply. Since it was wget that failed did I remove it (brew uninstall wget) and drush started working again, forcing it to use curl I guess. Reinstalled wget from homebrew again (brew install wget) but was no longer able to reproduce the problem. huh? wget though still fail if I manually test it
Is using curl stored somewhere? Does not look like it. It testes and use wget, does not run curl --version if it first find wget:
|
Yeah, if wget is in the $PATH, it will be used. Might be reasonable to add an option to select the preferred file-getting utility, but this would be a separate PR. |
I was getting the following with Drush master (just pulled latest changes to make sure I'm up to date, and ran
I then did I then reinstalled wget with |
Thanks for the above, but it did not work for me, re: reinstalling wget via homebrew.
I'm running MAMP with php5.5.26. I double checked wget is correctly pointing to this update and it seems to be.
Strange thing is though, running drush works with some other projects such as run |
The weird thing is:
(both http and https) While visiting same URL through browser gives a correct XML. I think something else is going on right now but I didn't figure it out yet. |
I think I figured it out. They now only support compressed requests:
|
Interesting, I tried with your example for linkit above in the browser, I saw the XML. However, I found field_collection's update URL https://updates.drupal.org/release-history/field_collection/7.x gives a "Not Found". Never come across this before, where do you even file an error like that, it's not really on the module...is it on project module https://www.drupal.org/project/project? EDIT: looks like you're making progress with the compressed requests :) |
Ah, found the issue about in Drupal.org while trying to create one: |
had this same problem on latest drush 7.4.0 , I am using php 5.6.x |
uninstalling and reinstalling wget was what finally resolved this issue for me. Thanks @geerlingguy! |
I had to uninstall brew's openssl and then re-install it with:
|
I ran into similar issues to this too, when running drush make/remake with patch files (with errors saying 'Unable to download ...') ... partly because drupal.org amazingly returns a 403 for .diff files when there is no user agent string! |
Drush performs multiple operations (downloading modules, etc.) using libcurl, but it does not currently restrict connections to TLS 1.0+. This could allow tampering or intercepting transferred data.
I'm not submitting this privately because POODLE is a generally known vulnerability that affects all SSL/TLS applications, and Drush is no more vulnerable than Chrome or Firefox right now.
The text was updated successfully, but these errors were encountered: