IssueTracker

It appears that 1.2 is in fact working in dev for python, according to this issue [1]. Could you show the error you receive when attempting to connect?

[1] https://code.google.com/p/googleappengine/issues/detail?id=10591

Additionally, could you show the code you use to connect?

Here is the information we have.

1) Stripe sent us this email:

In 2017, we'll be deprecating some of the older security protocols (TLS 1.0,
TLS 1.1, and SHA-1) used to make connections with Stripe's APIs. I'm reaching
out to give you an early heads up because your Stripe integration might be
impacted.

Here are some of the key upcoming dates:

* On January 1, 2017, we'll drop support for TLS 1.0 connections and SHA-1
  certificates.
* On May 1, 2017, we'll drop support for TLS 1.1 connections.

We've noticed that your Stripe integration appears to be using TLS 1.0, so
you'll want to follow the steps in this upgrade guide [1] to ensure that your
Stripe integration isn't interrupted in the next year.

To be clear, upgrading to TLS 1.2 will generally not involve any changes to
your code, but may require that you update your operating systems, system
packages, or language runtime libraries. (The exact methodology depends on your
technology stack.)

While you'll be required to make these changes to ensure that your Stripe
integration isn't interrupted, I'd like to stress that TLS 1.0, TLS 1.1, and
SHA-1 are widely considered to be dangerously weak and upgrading as early as
possible is an important part of keeping your business secure. If you'd like
more information about the topic, we've written up a blog post [2].

If you have any questions about this change, or need help in upgrading your
systems, please don't hesitate to ask—you can just reply to this email!

Thanks,

[1] https://support.stripe.com/questions/how-do-i-upgrade-my-stripe-integration-from-tls-1-0-to-tls-1-2
[2] https://stripe.com/blog/upgrading-tls

____________________________

2) Their instructions say to run a test. Here's the test:

import stripe

def test_stripe(request):
    stripe.api_key = "sk_test_BQokikJOvBiI2HlWgH4olfQ2"
    stripe.api_base = "https://api-tls12.stripe.com"
   
    if stripe.VERSION in ("1.13.0", "1.14.0", "1.14.1", "1.15.1", "1.16.0", "1.17.0", "1.18.0", "1.19.0"):
        return "Bindings update required."
   
    try:
        stripe.Charge.all()
        return "TLS 1.2 supported, no action required."
    except stripe.error.APIConnectionError:
        return "TLS 1.2 is not supported. You will need to upgrade your integration."    

When this test is run on the live server, including those under appspot.com, we get the first message, "TLS 1.2 supported, no action required."

When this test is run on a dev server, we get the second message, "TLS 1.2 is not supported. You will need to upgrade your integration." Note that we run our dev servers on MacOS, if that matters.

____________________________

3) Stripe tells us that calls made from the test environment are incorrect:

We've monitored all the accounts for TLS < 1.2 usage over the past few months to ensure that we caught anyone that could potentially be impacted. The reason is that some users have multiple integrations for one Stripe account and some of those are used less often but still need an upgrade.

I just looked into your Stripe account requests on our end to better understand what's causing this and I can confirm what you found. The issue seems to only happen in Test mode where your requests are made over TLS 1.0 instead of TLS 1.2. On the other end, all the requests made in production in Live mode have used TLS 1.2 for the past 30 days.

On our end, we have to deprecate those protocols as it's a requirement for PCI compliance. If we were to only enable this in Test it would be even worse as everything would seem to work fine and then fail once you go to production if you use the wrong protocol.

What I'd recommend here is to reach out to the AppEngine team so that they upgrade their installation to properly use TLS 1.2 in the Test environment too. The deprecation won't happen until January 2017 so I'm fairly confident this is something that will be fixed by then.

I hope this clarifies the situation but please do not hesitate to get back to me if you need more details.

____________________________

4) This is all the information we have. It's not our code, we're just one of tens of thousands of Stripe customers, and we have no special insight, nor any ability to change anything. We told Stripe that they should work with you directly, but they requested that we contact you, so we have. They said:

There are unfortunately thousands of host providers and we can't reach out to every single one especially as we're not their users and most will just ignore what we ask them to do.

I'd really recommend that you do contact them first as I'm sure they are aware of the upgrade requirements but I'll make a note to our engineering team to see if we could reach out to Google on our end.

The people who have communicated with us are:
Brandur Leach <brandur.leach@stripe.com>
Some guy named Thomas at integration@stripe.com

So ... it's up to you guys, not us. We just have to hope that you and Stripe get together and figure out what's going on.

Thanks

Thanks for the detailed reply. I'll try to get as much information about your situation as I can to determine next steps, but I'll need some help from your end in checking some things on your system:

1 .Could you check the version of tls used by your dev system by sending a urlfetch request to https://howsmyssl.com?

The response is a web page (html), so you'll want to echo that to the browser to view the results. This will tell you which version of tls you're using.

2. In the same code, could you attempt to run the following?

import google.appengine.api.urlfetch as urlfetch
import ssl
print urlfetch.__file__
print ssl.__file__
print ssl.OPENSSL_VERSION

This will show where on your system the urlfetch and ssl modules are being sourced from, and the openssl version.

3. Next, can you also run the following commands?

which dev_appserver.py

^^^ this will give you the location of your devserver process

4. Finally, if the dev_appserver.py script is in the google-cloud-sdk folder (gcloud), could you report the output of "gcloud info"? Otherwise, could you check what version of the App Engine SDK the script is residing in, and find the VERSION file in there, reporting its contents?

This isn't my problem or my company's problem. It's between you and Stripe. You want me to work on it. Stripe wants me to work on it. Why should I waste my time working on a problem that I have nothing to do with? Can't you people get together and work on it together?

Here's everything I have time for. Please direct future questions to the folks at Stripe.

I'm running El Capitan on MacOS. Another developer who tried it is also on El Capitan.

Just for grins, here's the answer to #1 in Chrome (which, of course, isn't being used when the problem occurs!) and in Safari (which, of course, also isn't being used when the problem occurs!). I have no idea what this stuff means and, frankly, I don't care.

The results of gcloud info are at the bottom. There's a warning in there. If it's an issue, then your installer has a bug because I have only installed (and updated) GAE with your installer and I do not have any other Google Cloud products installed. Here's my PATH:

/Users/REDACTED/google-cloud-sdk/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/misc/android-sdk-mac/tools

______
CHROME:

How's My SSL?
Home
About
API
Your SSL client is Probably Okay.
Check out the sections below for information about the SSL/TLS client you used to render this page.

Yeah, we really mean "TLS", not "SSL".

Version
Good Your client is using TLS 1.2, the most modern version of the encryption protocol. It gives you access to the fastest, most secure encryption possible on the web.

Learn More

Ephemeral Key Support
Good Ephemeral keys are used in some of the cipher suites your client supports. This means your client may be used to provide forward secrecy if the server supports it. This greatly increases your protection against snoopers, including global passive adversaries who scoop up large amounts of encrypted traffic and store them until their attacks (or their computers) improve.

Learn More

Session Ticket Support
Good Session tickets are supported in your client. Services you use will be able to scale out their TLS connections more easily with this feature.

Learn More

TLS Compression
Good Your TLS client does not attempt to compress the settings that encrypt your connection, avoiding information leaks from the CRIME attack.

Learn More

BEAST Vulnerability
Good Your client is not vulnerable to the BEAST attack because it's using a TLS protocol newer than TLS 1.0. The BEAST attack is only possible against clients using TLS 1.0 or earlier using Cipher-Block Chaining cipher suites that do not implement the 1/n-1 record splitting mitigation.

Learn More

Insecure Cipher Suites
Good Your client doesn't use any cipher suites that are known to be insecure.

Learn More

Given Cipher Suites
The cipher suites your client said it supports, in the order it sent them, are:

TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Learn More

_______
SAFARI:
How's My SSL?
Home
About
API
Your SSL client is Improvable.
Check out the sections below for information about the SSL/TLS client you used to render this page.

Yeah, we really mean "TLS", not "SSL".

Version
Good Your client is using TLS 1.2, the most modern version of the encryption protocol. It gives you access to the fastest, most secure encryption possible on the web.

Learn More

Ephemeral Key Support
Good Ephemeral keys are used in some of the cipher suites your client supports. This means your client may be used to provide forward secrecy if the server supports it. This greatly increases your protection against snoopers, including global passive adversaries who scoop up large amounts of encrypted traffic and store them until their attacks (or their computers) improve.

Learn More

Session Ticket Support
Improvable Session tickets are not supported in your client. Without them, services will have a harder time making your client's connections fast. Generally, clients with ephemeral key support get this for free.

Learn More

TLS Compression
Good Your TLS client does not attempt to compress the settings that encrypt your connection, avoiding information leaks from the CRIME attack.

Learn More

BEAST Vulnerability
Good Your client is not vulnerable to the BEAST attack because it's using a TLS protocol newer than TLS 1.0. The BEAST attack is only possible against clients using TLS 1.0 or earlier using Cipher-Block Chaining cipher suites that do not implement the 1/n-1 record splitting mitigation.

Learn More

Insecure Cipher Suites
Good Your client doesn't use any cipher suites that are known to be insecure.

Learn More

Given Cipher Suites
The cipher suites your client said it supports, in the order it sent them, are:

TLS_EMPTY_RENEGOTIATION_INFO_SCSV
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Learn More
_____

gcloud info

Google Cloud SDK [0.9.89]

Platform: [Mac OS X, x86_64]
Python Version: [2.7.10 (default, Oct 23 2015, 19:19:21)  [GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.5)]]
Python Location: [/usr/bin/python]
Site Packages: [Disabled]

Installation Root: [/Users/REDACTED/google-cloud-sdk]
Installed Components:
  core: [2015.11.30]
  core-nix: [2015.11.24]
  gcloud: []
  gsutil-nix: [4.15]
  gsutil: [4.16]
  bq: [2.0.18]
  bq-nix: [2.0.18]
System PATH: [/Users/REDACTED/google-cloud-sdk/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/misc/android-sdk-mac/tools:/Users/REDACTED/workspace/puzzazz/websetup]
Cloud SDK on PATH: [True]

WARNING: There are old versions of the Google Cloud Platform tools on your system PATH.
  /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/dev_appserver.py

Installation Properties: [/Users/REDACTED/google-cloud-sdk/properties]
User Config Directory: [/Users/REDACTED/.config/gcloud]
User Properties: [/Users/REDACTED/.config/gcloud/properties]
Current Workspace: [None]
Workspace Config Directory: [None]
Workspace Properties: [None]

Account: [REDACTED]
Project: [None]

Current Properties:
  [core]
    account: [REDACTED]
    disable_usage_reporting: [False]

Logs Directory: [/Users/REDACTED/.config/gcloud/logs]
Last Log File: [/Users/REDACTED/.config/gcloud/logs/2016.08.18/14.18.17.249691.log]

Thank you for your patience.

In order to help you determine what's going on in your system, it would be necessary to work with you to gather information. I had requested that you use urlfetch in the devserver to hit https://howsmyssl.com/ so that we could determine whether your devserver is using TLS 1.0 or 1.2. In an up-to-date SDK and system, 1.2 should be default, as I confirmed on my end, so it appears there's something going on in your system which won't be fixed by any change we make, even to the SDK, if you weren't to download a new one or take any further action. This would result in your inability to make calls in development to the Stripe API after they deprecate TLS 1.0 connections.

The other questions I asked about your system, about the python modules you have, were also directed towards determining where exactly the problem lies on your system. If you'd like to continue working on this issue, feel free to let me know, I'll be happy to assist.

Just to cut down some of the detail and make that more clear:

TLS 1.2 should be the default in an up-to-date system. The problem appears to exist on your installation, not with anything Google can change from our end, or which Stripe could influence from their end. I'm here and happy to help you ensure that you can get TLS 1.2 up and running. Feel free to ask any questions you may have, and if possible, run some of the diagnostics recommended in my prior comments.

This is very frustrating. I understand that there may be a problem in my configuration, but I don't see any way this could be something that we've done wrong. We've tested on multiple machines and they all exhibit the same problem. We have the current GAE SDK. We always update using the official installer. We are running El Capitan with nothing weird installed. I go out of my way to not install anything weird. Our app uses Python 2.7. The local version of Python is 2.7.10. The only thing that I can think of that might be unusual about our systems is that we have had GAE installed for a very long time, since 2010 and have continuously upgraded since then. Perhaps your installers have a problem in cases like this.

There's a limit to what I have time to deal with for a bug I haven't caused (we have plenty of our own things to deal with!) but I have done the four things you requested (see below). If you look at #3, you'll see that the import ssl fails because it can't import _ssl. Googling this finds we're not the only ones with this problem (no surprise there!). See:
* http://stackoverflow.com/questions/5128845/importerror-no-module-named-ssl
* http://stackoverflow.com/questions/16192916/importerror-no-module-named-ssl-with-dev-appserver-py-from-google-app-engine
* https://bugs.python.org/issue25526
Potential workarounds include building Python from source code (no, we won't be doing that, see above that I don't do anything weird)

There's also the suggestion of adding the following to app.yaml:

libraries:
- name: ssl
  version: latest

Yeah, pretty weird that, supposedly, we wouldn't get the latest SSL unless we explicitly ask for it, and no, it doesn't make a difference.

Hopefully, this is enough information that you can fix whatever the problem is in the next installer. This isn't urgent, but the sooner you fix it, the more likely it will be that GAE users will have the fix when Stripe turns off TLS 1.0.

____________
1. urlfetch https://howsmyssl.com/

 How's My SSL?
Home
About
API
Your SSL client is Bad.

Check out the sections below for information about the SSL/TLS client you used to render this page.

Yeah, we really mean "TLS", not "SSL".

Version

Bad Your client is using TLS 1.0, which is very old, possibly susceptible to the BEAST attack, and doesn't have the best cipher suites available on it. Additions like AES-GCM, and SHA256 to replace MD5-SHA-1 are unavailable to a TLS 1.0 client as well as many more modern cipher suites.

Learn More

Ephemeral Key Support

Good Ephemeral keys are used in some of the cipher suites your client supports. This means your client may be used to provide forward secrecy if the server supports it. This greatly increases your protection against snoopers, including global passive adversaries who scoop up large amounts of encrypted traffic and store them until their attacks (or their computers) improve.

Learn More

Session Ticket Support

Good Session tickets are supported in your client. Services you use will be able to scale out their TLS connections more easily with this feature.

Learn More

TLS Compression

Good Your TLS client does not attempt to compress the settings that encrypt your connection, avoiding information leaks from the CRIME attack.

Learn More

BEAST Vulnerability

Good Your client is not vulnerable to the BEAST attack. While it's using TLS 1.0 in conjunction with Cipher-Block Chaining cipher suites, it has implemented the 1/n-1 record splitting mitigation.

Learn More

Insecure Cipher Suites

Good Your client doesn't use any cipher suites that are known to be insecure.

Learn More

Given Cipher Suites

The cipher suites your client said it supports, in the order it sent them, are:

TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Learn More
____________
2. Importing SSL gets the following error shown in the console:

  File "/Users/REDACTED/admin.py", line 2104, in test_tls
    import ssl
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.py", line 97, in <module>
    import _ssl             # if we can't import it, let the error propagate
  File "/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/tools/devappserver2/python/sandbox.py", line 963, in load_module
    raise ImportError('No module named %s' % fullname)
____________
3. which dev_appserver.py gets:

/Users/REDACTED/google-cloud-sdk/bin/dev_appserver.py

There are no other copies of dev_appserver.py on my hard disk.
____________
4. gcloud info, same as reported earlier:

Google Cloud SDK [0.9.89]

Platform: [Mac OS X, x86_64]
Python Version: [2.7.10 (default, Oct 23 2015, 19:19:21)  [GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.59.5)]]
Python Location: [/usr/bin/python]
Site Packages: [Disabled]

Installation Root: [/Users/REDACTED/google-cloud-sdk]
Installed Components:
  core: [2015.11.30]
  core-nix: [2015.11.24]
  gcloud: []
  gsutil-nix: [4.15]
  gsutil: [4.16]
  bq: [2.0.18]
  bq-nix: [2.0.18]
System PATH: [/Users/REDACTED/google-cloud-sdk/bin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/Library/Frameworks/Mono.framework/Versions/Current/Commands:/misc/android-sdk-mac/tools:/Users/REDACTED/workspace/puzzazz/websetup]
Cloud SDK on PATH: [True]

WARNING: There are old versions of the Google Cloud Platform tools on your system PATH.
  /Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/dev_appserver.py

Installation Properties: [/Users/REDACTED/google-cloud-sdk/properties]
User Config Directory: [/Users/REDACTED/.config/gcloud]
User Properties: [/Users/REDACTED/.config/gcloud/properties]
Current Workspace: [None]
Workspace Config Directory: [None]
Workspace Properties: [None]

Account: [REDACTED]
Project: [None]

Current Properties:
  [core]
    account: [REDACTED]
    disable_usage_reporting: [False]

Logs Directory: [/Users/REDACTED/.config/gcloud/logs]
Last Log File: [/Users/REDACTED/.config/gcloud/logs/2016.08.18/14.18.17.249691.log]

I apologize for the frustration. The TLS v1.2 support was indeed fixed for the Python development server as of Jan 29, 2016. However the URL Fetch implementation on the development server depends directly on the local machine's installation of OpenSSL, which is most likely the reason you're only seeing TLS v1.0.

Even on El Capitan, it's a known issue that the default OpenSSL included is out of date, circa v0.9.8. You can check your OpenSSL version from the command line using 'openssl version'. The best way to update OpenSSL on Mac is to use Homebrew, and instructions for doing so are given on the Stripe support site:

How do I upgrade my OpenSSL to support TLS 1.2?
https://support.stripe.com/questions/how-do-i-upgrade-my-openssl-to-support-tls-1-2

To show that I've tested this, below is the code I'm using on the development server, with the output from https://howsmyssl.com (note the 'libraries' directive in app.yaml isn't needed unless you 'import ssl' directly). If you still have problems, you may want to test on a clean system using the latest SDK version (1.9.42) from the ZIP installer, which is now the same SDK used on Windows, Mac and Linux:

----- app.yaml:
application: <redacted>
version: <redacted>
runtime: python27
api_version: 1
threadsafe: true

handlers:
- url: /.*
  script: main.app

----- main.py:
import webapp2

from google.appengine.api import urlfetch

class MainPage(webapp2.RequestHandler):

  def get(self):
    from google.appengine.api import urlfetch
    url = 'https://howsmyssl.com'
    fetched = urlfetch.fetch(url, validate_certificate=False)
    self.response.write(fetched.content)

app = webapp2.WSGIApplication([('/', MainPage)], debug=True)

---- application output:
Your SSL client is Probably Okay.

Check out the sections below for information about the SSL/TLS client you used to render this page.

Yeah, we really mean "TLS", not "SSL".

Version
Good Your client is using TLS 1.2, the most modern version of the encryption protocol. It gives you access to the fastest, most secure encryption possible on the web.

Ephemeral Key Support
Good Ephemeral keys are used in some of the cipher suites your client supports. This means your client may be used to provide forward secrecy if the server supports it. This greatly increases your protection against snoopers, including global passive adversaries who scoop up large amounts of encrypted traffic and store them until their attacks (or their computers) improve.

Session Ticket Support
Good Session tickets are supported in your client. Services you use will be able to scale out their TLS connections more easily with this feature.

TLS Compression
Good Your TLS client does not attempt to compress the settings that encrypt your connection, avoiding information leaks from the CRIME attack.

BEAST Vulnerability
Good Your client is not vulnerable to the BEAST attack because it's using a TLS protocol newer than TLS 1.0. The BEAST attack is only possible against clients using TLS 1.0 or earlier using Cipher-Block Chaining cipher suites that do not implement the 1/n-1 record splitting mitigation.

Insecure Cipher Suites
Good Your client doesn't use any cipher suites that are known to be insecure.

Given Cipher Suites
The cipher suites your client said it supports, in the order it sent them, are:
<long list of supported ciphers>

So it's Apple's fault. At least that clears up where the problem is.

I do not have a brew command on my system, nor do any of the other machines at our company. It is my strong preference to keep machines as stock as possible and I don't like the idea of installing unofficial system software or some third party package installer I've never heard of before. And our new machine setup instructions are already complicated enough. Are you aware of any more official way of upgrading openssl?

Also, when I google for the openssl issue, I find many, many people have encountered this problem in many different ways. Is there some way for Google (and Stripe) to help communicate this better? It seems like perhaps we could have short-circuited this whole process with a "you probably have the outdated version of openssl known to exist in El Capitan".

I hope this message finds you well. We've identified a possible workaround for this case.

You could start by installing https://www.python.org/ftp/python/2.7.12/python-2.7.12-macosx10.6.pkg and seeing what OpenSSL it comes with. We tested this and found that it is still using version 0.9.8zh, even when upgraded with the latest pyOpenSSL from PyPi.

According to https://eclecticlight.co/2016/03/23/the-tls-mess-in-os-x-el-capitan/:

"""
among the many security fixes in OS X 10.11.4, LibreSSL was updated to version 2.1.8, and OpenSSL to 0.9.8zh.
"""

It appears you were using version 0.9.8.zg (a pre-10.11.4 version), and while even version zh is not sufficient for TLS 1.2, this possibly points to the need (not essential to this specific issue but good in general) to install OS X security fixes. We can confirm the version is zh on a 10.11.6 Mac using Apple's own Python.

To get a more modern openssl, miniconda works -- see http://conda.pydata.org/miniconda.html (the installer also prepends the path to the binaries it installs in .bash_profile -- the new PATH is activated when a new Terminal app is opened).

With miniconda (We're running it explicitly from the path where it got installed):

```
$ /Users/username/miniconda2/bin/python

Python 2.7.12 |Continuum Analytics, Inc.| (default, Jul  2 2016, 17:43:17)

[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)] on darwin

Type "help", "copyright", "credits" or "license" for more information.

Anaconda is brought to you by Continuum Analytics.

Please check out: http://continuum.io/thanks and https://anaconda.org

>>> import ssl

>>> ssl.OPENSSL_VERSION

'OpenSSL 1.0.2h  3 May 2016'

>>>
```

Could you attempt this and let us know the results when using dev_appserver.py? You may need to work with your path to ensure that version of python is running rather than the system default.

Thanks for the thoughts. What I'm going to do is wait and install macOS Sierra and see if Apple has updated the SSL sufficiently that the problem goes away. If not, I'll look into your suggestions.

It's not likely that the next version of macOS will update OpenSSL, as per this statement on the Apple Developer Site [1]:

"Although OpenSSL is commonly used in the open source community, OpenSSL does not provide a stable API from version to version. For this reason, although OS X provides OpenSSL libraries, the OpenSSL libraries in OS X are deprecated, and OpenSSL has never been provided as part of iOS. Use of the OS X OpenSSL libraries by apps is strongly discouraged.

If your app depends on OpenSSL, you should compile OpenSSL yourself and statically link a known version of OpenSSL into your app. This use of OpenSSL is possible on both OS X and iOS. However, unless you are trying to maintain source compatibility with an existing open source project, you should generally use a different API.

Common Crypto and Security Transforms are the recommended alternatives for general encryption. CFNetwork and Secure Transport are the recommended alternatives for secure communications."

The alternative APIs mentioned only work within the Apple ecosystem, so for cross-platform environments such as Python it's necessary to manually update OpenSSL as per Apple's recommendation.

[1] https://developer.apple.com/library/mac/documentation/Security/Conceptual/cryptoservices/GeneralPurposeCrypto/GeneralPurposeCrypto.html

Since this has been located as an issue on the development machine rather than the SDK, this issue should close WorkAsIntended soon. Would you like to make a specific feature request in connection with this issue?

This issue will close soon due to inactivity. Feel free to reply to the last comment some time in the next 5 days and we'll be happy to assist.

This issue has now closed due to inactivity. If you'd like to make a feature request or issue report in future, please feel free to do so. We'll be happy to assist!

I do have the same issue. Please help to resolve this.

Ran
import ssl
urlfetch.__file__ = '/Applications/GoogleAppEngineLauncher.app/Contents/Resources/GoogleAppEngine-default.bundle/Contents/Resources/google_appengine/google/appengine/api/urlfetch.pyc'
ssl.__file__ = '/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/ssl.pyc'
ssl.OPENSSL_VERSION = 'OpenSSL 0.9.8zh 14 Jan 2016'

Note: In terminal when I give "openssl version", the response is 'OpenSSL 1.1.0c  10 Nov 2016'. This is after I went through a series of steps to upgrade OpenSSL in /usr/bin in mac.

Ran  urlfetch on 'https://howsmyssl.com/?'. Following is the response.

Your SSL client is Bad.

Check out the sections below for information about the SSL/TLS client you used to render this page.

Yeah, we really mean "TLS", not "SSL".

Version

Bad Your client is using TLS 1.0, which is very old, possibly susceptible to the BEAST attack, and doesn't have the best cipher suites available on it. Additions like AES-GCM, and SHA256 to replace MD5-SHA-1 are unavailable to a TLS 1.0 client as well as many more modern cipher suites.

Learn More

Ephemeral Key Support

Good Ephemeral keys are used in some of the cipher suites your client supports. This means your client may be used to provide forward secrecy if the server supports it. This greatly increases your protection against snoopers, including global passive adversaries who scoop up large amounts of encrypted traffic and store them until their attacks (or their computers) improve.

Learn More

Session Ticket Support

Good Session tickets are supported in your client. Services you use will be able to scale out their TLS connections more easily with this feature.

Learn More

TLS Compression

Good Your TLS client does not attempt to compress the settings that encrypt your connection, avoiding information leaks from the CRIME attack.

Learn More

BEAST Vulnerability

Good Your client is not vulnerable to the BEAST attack. While it's using TLS 1.0 in conjunction with Cipher-Block Chaining cipher suites, it has implemented the 1/n-1 record splitting mitigation.

Learn More

Insecure Cipher Suites

Good Your client doesn't use any cipher suites that are known to be insecure.

Learn More

Given Cipher Suites

The cipher suites your client said it supports, in the order it sent them, are:

TLS_DHE_RSA_WITH_AES_256_CBC_SHA
TLS_DHE_DSS_WITH_AES_256_CBC_SHA
TLS_DHE_RSA_WITH_AES_128_CBC_SHA
TLS_DHE_DSS_WITH_AES_128_CBC_SHA
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_EMPTY_RENEGOTIATION_INFO_SCSV
Learn More

Please see post #11 to see that the issue on your system is related to the version of openssl you're using

https://code.google.com/p/googleappengine/issues/detail?id=13207#c11