初心者向けにわかりやすく解説するssl_newの利用手順と内部動作

2025 9/27

2025/09/27

はじめに

ブログの記事をどう書けばいいかわからない、という疑問をお持ちではありませんか？本記事はOpenSSLのSSL_new関数に焦点を当て、使い方や内部動作、実践例まで丁寧に解説します。SSL_newはSSL/TLS通信で接続オブジェクトを生成する中心的な関数です。初期化から終了までの流れを理解すると、安全な通信を実装しやすくなります。

この記事の目的

SSL_newの役割を分かりやすく伝え、実際の利用方法やデバッグに役立つ知識を提供します。専門用語は最小限にし、具体例で補足しますので、実装経験が浅い方でも読み進められます。

対象読者

SSL/TLSの基本は知っているが実装に不安がある開発者
OpenSSLを使った通信の実装や解析を学びたいエンジニア
SSL_newの内部設計に興味がある研究者や学生

本記事の構成（全8章）

はじめに（本章）
SSL_newとは何か
利用手順と役割
内部動作・設計
具体的なサンプルコード
BIOとの連携とデータフロー
デバッグやパケットキャプチャへの応用
バージョンによる追加機能や注意点

この章を読み終えると、記事全体の流れがつかめます。次章から具体的な説明に入っていきます。

SSL_newとは何か

概要

SSL_newは、OpenSSLが提供する関数で、SSL/TLS通信を行うための「SSL接続オブジェクト」を作成します。事前に作成したSSL_CTX（SSLコンテキスト）を元に、新しいSSL構造体を割り当てて返します。これは安全な通信を開始するための準備段階に当たります。

シグネチャと引数

SSL *SSL_new(SSL_CTX *ctx);

引数にはSSL_CTXへのポインタを渡します。SSL_CTXには証明書や鍵、プロトコル設定などをまとめておきます。SSL_newはその設定を引き継いだSSLオブジェクトを生成します。

戻り値とエラー処理

戻り値は新しく割り当てられたSSLポインタで、失敗時はNULLを返します。NULLが返った場合は、エラーコードを確認して原因を特定します。作成に成功したら、通信が終わったらSSL_freeで解放する必要があります。

使い方のイメージ

サーバ／クライアントで共通: まずSSL_CTXを初期化・設定します。
次にSSL_newでSSLオブジェクトを作成します。
ソケットと紐づけて（例: BIOやSSL_set_fdを使い）SSL_connect/SSL_acceptを呼びます。

注意点

SSL_new自体は接続を確立しません。接続処理はSSL_connectやSSL_acceptが担当します。
メモリ管理に注意し、不要になったら必ずSSL_freeを呼んでください。
多数の接続を扱う際は、SSL_CTXを使い回してSSL_newを繰り返し呼ぶのが効率的です。

以上がSSL_newの基本的な役割と使い方の概観です。

SSL_newの利用手順と役割

概要

SSL/TLSを使った通信を実装する際は、まず共通の設定を持つコンテキスト（SSL_CTX）を作り、つぎに接続ごとの状態を持つSSLオブジェクトを生成します。SSL_newはその接続ごとの状態オブジェクトを作る役割です。

利用手順（順序）

SSL_CTXを作成する：SSL_CTX_new()
SSLオブジェクトを作る：SSL_new(ctx)
ソケットを割り当てる：SSL_set_fd(ssl, fd)またはBIOを接続
ハンドシェイクを開始：クライアントはSSL_connect(), サーバはSSL_accept()
データ送受信：SSL_write()/SSL_read()
終了と解放：SSL_shutdown(), SSL_free()

コードの流れを単純に示すと:
SSL_CTX ctx = SSL_CTX_new(…);
SSL ssl = SSL_new(ctx);
SSL_set_fd(ssl, fd);
SSL_connect(ssl);
SSL_write(ssl,…);
SSL_read(ssl,…);
SSL_shutdown(ssl);
SSL_free(ssl);

SSL_newの具体的な役割

接続ごとの暗号化・復号の状態（鍵やIVの管理）を保持します。
ハンドシェイクの進行状況や相手の証明書情報を保持します。
SSL_CTXの設定や証明書を参照しますが、設定自体は共有されます。

実践上の注意

SSLオブジェクトは接続ごとに1つ作り、スレッド間で共有しないでください。
ノンブロッキングI/Oでは戻り値とエラー処理を必ず扱ってください。
最後にSSL_shutdownしてからSSL_freeでリソースを解放します。

SSL_newの内部動作・設計

概観

SSL_newは「設計図（SSL_CTX）」から接続ごとのインスタンス（SSL構造体）を生成します。例えると、SSL_CTXが家の設計図なら、SSL_newはその図面を元に一軒の家を建てる作業です。個別設定はインスタンス単位で保持し、共通設定は設計図で管理します。

メモリ確保と初期化

呼び出すとまずSSL構造体のメモリを確保し、フィールドを初期値で埋めます。内部でハンドシェイクの状態やシーケンス番号、暗号スイート選択用のデータを用意します。必要なら乱数やタイムスタンプも初期化します。

SSL_CTXとの関係

SSL_newは渡されたSSL_CTXへの参照を増やします（参照カウントをインクリメント）。設計図の証明書や検証設定、暗号ポリシーは共有しますが、セッションやソケットなど接続固有の情報はSSL構造体側に格納します。これにより多数接続を効率的に扱えます。

コールバックとカスタマイズ

鍵ログや証明書検証などのコールバックはインスタンスにセットできます。デフォルトでは設計図の設定をコピーしますが、必要に応じて上書きできます。アプリ固有のデータを保存するためのex_data領域も用意されます。

所有権と解放

生成に成功するとSSL_freeで解放します。解放時にSSL_CTXの参照を減らし、最後の参照がなくなると設計図も解放されます。

エラー処理と注意点

ctxがNULLだったりメモリ不足だとNULLを返し、エラーを設定します。共有と個別の役割を理解し、設計図(SSL_CTX)を適切に管理することが安全運用の鍵です。

具体的なサンプルコード

簡単なサーバ例（libevent連携）

以下は最小限の流れを示した例です。証明書と秘密鍵は事前に用意してください。

/* 初期化（1回） */
SSL_CTX *ctx = SSL_CTX_new(TLS_server_method());
SSL_CTX_use_certificate_file(ctx,"cert.pem",SSL_FILETYPE_PEM);
SSL_CTX_use_PrivateKey_file(ctx,"key.pem",SSL_FILETYPE_PEM);

/* libevent の接続コールバック内で */
void on_accept(evconnlistener *l, evutil_socket_t fd, struct sockaddr *sa, int len, void *arg){
    int cli_fd = fd; /* 受け取ったソケット */
    SSL *ssl = SSL_new(ctx);
    SSL_set_fd(ssl, cli_fd);
    if (SSL_accept(ssl) <= 0) { /* ハンドシェイク失敗 */
        SSL_free(ssl);
        close(cli_fd);
        return;
    }
    /* 成功したら読み書き */
    const char *msg = "Hello TLS\n";
    SSL_write(ssl, msg, strlen(msg));
    /* 終了処理 */
    SSL_shutdown(ssl);
    SSL_free(ssl);
    close(cli_fd);
}

ポイント解説

SSL_CTX_new: サーバ用の設定コンテキストを作ります。
SSL_new: その接続ごとのオブジェクトを生成します。ソケットを割り当てる前に作ります。
SSL_set_fd: ソケットをSSLオブジェクトに結び付けます。
SSL_accept: TLSハンドシェイクを実行します。成功すればデータ送受信できます。
SSL_write / SSL_read: 暗号化された送受信を行います。普通の send/recv と置き換えて使います。
SSL_shutdown / SSL_free: 通信終了とオブジェクト解放を行います。

この流れを libevent の接続イベント内で行えば、イベント駆動で複数接続を扱えます。エラー処理やノンブロッキング対応は実運用で追加してください。

BIOとの連携とデータフロー

BIOの役割

BIOは入出力を抽象化するバッファです。SSLはアプリケーションデータとネットワーク上の暗号化データを直接やり取りせず、BIOを介して分離します。これにより非同期処理やメモリ上での検査が容易になります。

送信側のデータフロー（簡潔）

アプリがSSL_write()を呼ぶと、平文はSSL内部で暗号化され、書き出し用BIO（wbio）に格納されます。
アプリはBIO_read()でwbioから暗号化データを取り出し、ソケットへ送信します。

例（擬似コード）:

SSL_write(ssl, appbuf, len);
while((n=BIO_read(wbio,out,sz))>0) send(sock,out,n);

受信側のデータフロー（簡潔）

ソケットで受け取った暗号化データをBIO_write()で読み込み用BIO（rbio）に入れます。
アプリがSSL_read()を呼ぶと、rbioからデータを取り出して復号し平文を返します。

例:

n = recv(sock,in,sz);
BIO_write(rbio,in,n);
r = SSL_read(ssl, appout, sz);

ノンブロッキングや部分送受信の扱い

BIOやSSLは部分的な読み書きを返すことがあります。SSL_read()/SSL_write()がSSL_ERROR_WANT_READやSSL_ERROR_WANT_WRITEを返したら、対応するBIOから送信データを取り出すか、追加受信を待ちます。メモリBIOを使うと、タイミング制御やテストがとても簡単になります。

実用ポイント

メモリBIOはプロキシやテストで便利です。暗号化済みバイト列を容易に解析できます。
ソケットBIOを設定すれば自動送受信が可能ですが、細かい制御が必要な場面では手動でBIO経由にします。
バッファのサイズと部分読み書きに注意して、ループで確実に処理してください。

デバッグやパケットキャプチャへの応用

フックとコールバックで狙いを絞る

SSL_newの直後やSSL構築時にフックを仕込み、必要な情報を取り出します。例えばSSLオブジェクトに独自データを紐付けるにはex_data機構(SSL_set_ex_data/SSL_get_ex_data)を使います。これで接続単位の状態を保持できます。

セッション鍵のロギング

SSL_CTX_set_keylog_callbackを登録すると、セッション鍵やTLSハンドシェイク情報をログに出せます。Wiresharkでその鍵ログを読み込めば、暗号化パケットを復号して内部を確認できます。実運用では鍵漏洩に注意して一時的にのみ有効化してください。

メッセージ単位の観測

SSL_set_msg_callbackやSSL_CTX_set_info_callbackでハンドシェイクやレコードの流れを監視できます。ログにバイト列やフェーズを書き出すと、どの段階で問題が起きているか特定しやすくなります。

証明書検証を緩めたリアルタイムデバッグ

開発環境ではコールバックで検証を一時的にスキップし、通信内容や動作を確認できます。ただし本番では絶対に無効化しないでください。

パケットキャプチャとの連携例

1) アプリで鍵をSSL_CTX_set_keylog_callbackに出力
2) tcpdump/pcapでトラフィックを取得
3) Wiresharkに鍵ログを読み込ませ復号して解析

注意点

ログに平文鍵や機密情報を残すと重大なリスクになります。アクセス制御と有効期間の限定を徹底してください。

OpenSSLバージョンによる追加機能や注意点

概要

OpenSSLのバージョンが変わると、SSL_newを使うアプリケーションで利用できる機能や安全性が変化します。ここでは主要バージョンごとの違いと実務上の注意点をやさしく説明します。

主なバージョン別のポイント

1.0.1〜1.0.2: TLS1.2のサポートやECDHE（前方秘匿性）の普及が進みました。SNI（サーバ名指示）も実用的になり、複数ドメイン対応が楽になります。
1.1.0: 初期化処理が自動化され、従来のSSL_library_initなどを明示的に呼ぶ必要がなくなりました。構造体の非公開化でAPIの取り扱いが簡潔になります。
1.1.1: TLS1.3をサポートし、接続の速度と安全性が向上します。TLS1.3はハンドシェイク回数が少なく、暗号スイートの選定が簡単になります。
3.0: 大幅な設計変更（プロバイダーモデルの導入、互換性の注意）が入ります。古いAPIや暗号が非推奨になります。

注意点と対策

実装依存: ビルド時のOpenSSLヘッダと実行時のライブラリが異なると不具合が出ます。必ず同一バージョンでビルド・テストしてください。
設定変更: 暗号の優先順やプロトコル最小値は明示的に設定します。例: SSL_CTX_set_min_proto_version(ctx, TLS1_2_VERSION)やTLS1.3対応の確認。
互換性: 古いクライアントを相手にする場合、古いプロトコルの無効化が影響することがあります。ログやパケットキャプチャで確認しましょう。