結論

できない

経緯

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

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

序章：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の僕が現れたときに何かの役に立ちますように…

俺の２月返してくれ！

元記事はこちら

「Device Farm(appium python)からAPI Gatewayにリクエストを投げる」