ssl:connect/2,3 has no support for {verify, verify_peer} on the client side — process_options/3 crashes with function_clause

オープン
  • 何か問題がありますか？
#2,401 コメント 1 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
48/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
静か
技術スタック
embedded-iot, erlang
領域
networking, security

調査の方向性

Start in libs/estdlib/src/ssl.erl, where the issue identifies process_options/3 and the tls_client_option() type. Read the client connection option handling and its tests, then check how certificate authorities are configured in this project. Done means verify_peer either verifies the peer against a supplied CA or returns a clear unsupported option error instead of crashing.

索引モデルが issue の本文から書いたものです。

説明

Summary

libs/estdlib/src/ssl.erl's client-connect path only supports
{verify, verify_none}. Passing {verify, verify_peer} — the option that
actually asks for certificate verification against a trust store — crashes
the calling process with function_clause, since process_options/3 has no
clause for it:

-spec process_options(
    SSLContext :: sslcontext(), SSLConfig :: sslconfig(), TLSOptions :: [tls_client_option()]
) -> ok.
process_options(_SSLContext, _SSLConfig, []) ->
    ok;
process_options(SSLContext, SSLConfig, [{server_name_indication, disabled} | Tail]) ->
    process_options(SSLContext, SSLConfig, Tail);
process_options(SSLContext, SSLConfig, [{server_name_indication, Hostname} | Tail]) ->
    ok = ?MODULE:nif_set_hostname(SSLContext, Hostname),
    process_options(SSLContext, SSLConfig, Tail);
process_options(SSLContext, SSLConfig, [{verify, verify_none} | Tail]) ->
    ok = ?MODULE:nif_conf_authmode(SSLConfig, none),
    process_options(SSLContext, SSLConfig, Tail);
process_options(SSLContext, SSLConfig, [{binary, true} | Tail]) ->
    process_options(SSLContext, SSLConfig, Tail);
process_options(SSLContext, SSLConfig, [binary | Tail]) ->
    process_options(SSLContext, SSLConfig, Tail);
process_options(SSLContext, SSLConfig, [{active, false} | Tail]) ->
    process_options(SSLContext, SSLConfig, Tail).

The module's own type spec agrees this is intentional, not an oversight —
verify_peer simply isn't a valid value yet:

-type tls_client_option() ::
    {server_name_indication, sni()} | {verify, verify_none}.
Reproduction
{ok, Socket} = socket:open(inet, stream, tcp),
ok = socket:connect(Socket, #{family => inet, addr => ..., port => 443}),
ssl:connect(Socket, [{active, false}, {verify, verify_peer}]).

crashes with:

{updater_crashed, {function_clause, []}}

(stacktrace comes back empty — AtomVM doesn't currently capture one for this
kind of crash, which made this harder to pin down than it should have been;
a {error, {unsupported_option, {verify, verify_peer}}} return, or at least
a non-empty stacktrace, would help here.)

Where this actually bit us

nerves_hub_link_atomvm_esp32's
OTA downloader (nh_ota.erl) connects to the firmware URL with
ahttp_client:connect(https, Host, Port, [{active, false}, {verify, verify_peer}]),
intending real certificate verification of the download host (a signed
firmware payload doesn't need it, but it's defense in depth). That call
crashes every OTA attempt with exactly this function_clause. We've patched
it locally to verify_none to keep testing (the firmware payload is still
checksummed independently, so this isn't a security hole for that project,
just a missing layer), but verify_peer is the option anyone would reach
for first, and AtomVM's own ssl.erl type spec says it should exist.

Environment
  • AtomVM: main @ 0220c78e (v0.7.0-alpha.1-211-g0220c78e)
  • Target: esp32 (ESP32-D0WDQ6, classic dual-core, no PSRAM)
  • ESP-IDF: v5.5.2
What would help

Either:

  • Implement {verify, verify_peer} against a supplied CA (cacerts/
    cacertfile-style option), matching the type spec that already promises
    it, or
  • If it's not implemented yet on purpose, update the type spec/docs to say
    so explicitly and return a clear {error, ...} instead of a bare
    function_clause with no stacktrace, so it fails obviously rather than
    looking like a caller bug.

Happy to help test a patch against real hardware — this came up debugging a
live NervesHub OTA update on an ESP32.

主要言語
Erlang
スター
2.3k
フォーク
171
平均マージ
5日 11時間
マージ済み PR（30日）
19

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

atomvm/AtomVM のほかの issue

atomvm/AtomVM の issue をすべて見る

似ている issue

Networking の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。