結論

できない

経緯

ふえぇ。結論から先に言えってえらいおにいさんたちが言うから結論から書いたんだよぅ。
というわけで経緯です。

序章：SSL handshake failure編
本題：subprocessでサーバーのぞいちゃうぞ編
終章：俺の２月返してくれ編

序章：SSL handshake failure編

ごく普通のイケメンエンジニア、たかはしマンは現在関わっているプロダクトを次の形へと進化させるべく奮闘していた。

AWSのDevice Farm上で動くappium-pythonのコードからAPI Gateway + LambdaでたてたサーバーレスなAPIを利用して、動的にデバイステストを行おうと考えたのだ。

朝起きてすぐに背伸びをするようにパッケージをインストールし、

$ pip install requests

背骨が伸びるとともに吸い込んだ息を吐き出すように、そう、いつものルーチンでrequestsを書いた。

response = requests.post(
    url,
    headers=headers,
    data=json.dumps(payload)
)

return response.json()

PHPerからPythonistaになってから毎日やってきた動作だ。何も怖いものなんてない。
優しくパッケージングしてDevice Farmに流し込む。
余談だが、たかはしマンは deploy.sh という何もdeployしないパッケージング用のシェルを用意していた。
Device Farmに流し終われば、あとはコードにミスがないかを細かく直していけば終わりだ。

SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure

たかはしマンは、息を呑んだ。

本題：subprocessでサーバーのぞいちゃうぞ編

めんどくさくなったので本題はさくっと終わらせます。
subprocessで超潜ったのでわかったことだけ書きます。

SSLv3はPOODLEとかいろんな脆弱性で死んだ
requests-toolbeltつかってもだめ
PyOpenSSLいれようとするとwheelが none-any になってないからだめ
もともとPyOpenSSLはいってた
opensslのバージョンは1.0.0
使える最新SSLバージョンはTLSv1
暗号スイートはAPI Gatewayにも使えるやつがあった
curlではTLSv1で外につなぎにいくことが可能

終章：俺の２月返してくれ編

API Gatewayはクライアント側のSNI対応が必須
Python側は2.7.9からSNIに対応
Device Farm内のPythonバージョンは2.7.6

リバプロするかcurlで頑張ってパースするしかないんだって...

宝の地図も、宝もあるかわからないところに潜った結果がコレ。
たぶん世界でもこんな罠踏んだ人いないと思うけど、第２、第3の僕が現れたときに何かの役に立ちますように...

俺の２月返してくれ！