openssl、curl、php、nginxでGOST証明書をサポートするDockerイメージ

この記事では、 GOST R 34.10-2001 （非推奨）およびGOST R 34.10-2012で定義されたアルゴリズムを使用して機能するサービスとテストモードでの統合の問題をどのように解決したかについて説明します。 問題を解決する際に遭遇したいくつかの問題の例を挙げ、既成のソリューションへのリンクを与え、その使用例をいくつか示します。

理由

そもそも、本番環境には「Cryptocom」、「Crypto-Pro」、「Signal-COM」などの企業から認定された資金があると言っておく価値があります。 Linuxのテスト（開発）環境で相互作用を実装する必要がありました。このためのライセンスの購入はあまり便利ではありませんが、さらに悪いことに、この問題に関するオープンアクセスドキュメントはありません。 「https gost」のリクエストでは、多くの解決策はありません。 その中でも、OpenSSL + Crypto CSPの使用が言及されていますが、詳細は覚えていませんが、GOST R 34.10-2012をサポートするこのバンドルは入手できませんでした。 よく出会った別の結果は、GOSTエンジンが組み込まれているOpenSSL 1.0を使用する提案でしたが、このソリューションにはGOST2012-GOST8912-GOST8912



サポートも含まれていませんGOST2012-GOST8912-GOST8912



。

実用的なソリューションは、OpenSSL 1.1.0g +のアセンブリであり、個別に接続された動的GOSTエンジンエンジンで取り出されました。 特定のロシアの会社がそれを開発する努力をしたとインターネットでしばしば言及されますが、リポジトリ自体には製品の作者に関する情報がありません。 この機会に、著者にオープンソースエンジンを感謝します。 このページでは、OpenSSL 1.1.0以前では、組み込みのGOSTエンジンが使用されていましたが、GOSTはOpenSSLのサードパーティ製品を使用するようになりました。 構成から判断すると、おそらくこれは同じライブラリーです。

OpenSSL、GOSTエンジン、cURLを構築する

これをほとんど行わない人のためにサードパーティ製品を組み立てることは、簡単な作業ではありません。 OpenSSL、GOSTエンジン、およびcURLを構築するには、多数のオプションを見つけ出し、バージョンのいくつかの組み合わせを試す必要がありました。 Dockerfileに奇妙なことに気付いた場合、おそらくこのような実験からこれが残っています。

更新のために何かが機能しなくなる状況を排除するために、プロジェクトのすべてのバージョンのアセンブリを修正しました。 たとえば、OpenSSL 1.1.0h + GOST-engineを作成し、 openssl ciphers



ciphersコマンドにGOST-algorithmsが含まれていませんでしたが、 openssl engine



のリストにはGOST-engineが表示されていました。 OpenSSL 1.1.0gの以前のバージョンを指定することにより、すべてが期待どおりに機能しました。 それは非常に奇妙でした、私はそれをもう一度繰り返し、それから私は理由を見つけようとしましたが、結局1.1.0gにとどまることにしました。

GOSTエンジン自体を収集しましたが、不明なドキュメントからブランチからopenssl_1_1_0



を収集したため、すぐにmasterブランチのINSTALL.md



ファイルの存在に注意を払いませんでした。 そのバージョンは、OpenSSLチームのカスタムビルドで構築されました

 cmake -DCMAKE_C_FLAGS='-I/usr/local/ssl/include -L/usr/local/ssl/lib' ..
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

しかし、masterブランチはこのように収集を停止し、 DOPENSSL_ROOT_DIR



などが存在しないことに関するエラーが発生しました。 その結果、解決策が見つかり修正されました。

OpenSSLのカスタムアセンブリを使用してcURLを構築するためのドキュメントははるかに多くありますが、ドキュメントは時代遅れになり、オプションを試してみる必要がありました。

作業の結果はここに投稿されます 。

イメージはDocker Hubで起動されます。

OpenSSL + GOST-engineの使用例

Dockerイメージの操作の詳細については説明しません。イメージ内で作業を開始するコマンドを1つだけ入力します。

 docker run --rm -i -t rnix/openssl-gost bash
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

まず、 GOST2012-GOST8912-GOST8912



およびGOST2001-GOST89-GOST89



がサポートされているもののリストにあることを確認できます。

 openssl ciphers
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GOSTアルゴリズムに基づいてHTTPSで実行されるホストを知っている場合、その証明書を確認して、コマンドを使用して接続を試行できます。

 openssl s_client -connect gost.example.com:443 -showcerts
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

GOST R 34.10-2012に従って秘密鍵と証明書を作成します。

 openssl req -x509 -newkey gost2012_256 -pkeyopt paramset:A -nodes -keyout key.pem -out cert.pem
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

以前に作成した証明書でファイルに署名します。

 openssl cms -sign -signer cert.pem -inkey key.pem -binary -in file.txt -nodetach -outform DER -nocerts -noattr -out signed.sgn
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

署名されたファイルの内容を、それ自体で署名された証明書で抽出します。

 openssl cms -verify -in signed.sgn -certfile cert.pem -CAfile cert.pem -inform der -out data.txt
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

証明書自体の署名を使用すると、事態はもう少し複雑になります。 これまでのところ、信頼できる認証局によって発行された証明書を持つサービスに出くわしていません。 通常、発行された証明書を使用する場合は、認証センターの証明書を追加で示す必要があります。 これは、システム（イメージ内）に対してグローバルに実行することも、各コマンドで明示的に指定することもできます。

使用中のcURLプログラムは変更されておらず、GOST証明書を持つホストのみをサポートしています。

プログラミング言語での作業での画像の使用

プログラミング言語がシステムにインストールされたプログラムの実行を許可する場合、GOSTアルゴリズムを使用するタスクは、 マルチステージビルドを使用してDockerfileプログラミング言語の最後にコンパイルされたopensslおよびcurlのバイナリをコピーすることで最も簡単に解決されます。 例：

 FROM rnix/openssl-gost AS openssl-gost # Replace with any other image based on Debian x86_64 FROM debian:stretch-slim COPY --from=openssl-gost /usr/local/ssl /usr/local/ssl COPY --from=openssl-gost /usr/local/ssl/bin/openssl /usr/bin/openssl COPY --from=openssl-gost /usr/local/curl /usr/local/curl COPY --from=openssl-gost /usr/local/curl/bin/curl /usr/bin/curl COPY --from=openssl-gost /usr/local/bin/gostsum /usr/local/bin/gostsum COPY --from=openssl-gost /usr/local/bin/gost12sum /usr/local/bin/gost12sum
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

/usr/bin



にコピーする必要さえありません。これを任意のディレクトリで実行し、プログラムから呼び出して、フルパスとすべての引数を渡すことができます。

PHPでのGOSTアルゴリズムのサポート

もちろん、PHPでは、たとえばexec



を使用してシステムコマンドを呼び出すことができます。 しかし、PHP-FPMがDockerfileでどのように構築されるかを見ると、カスタムOpenSSLおよびcURLアセンブリを使用してPHPを簡単に構築できるように思えました。 さらに判明したように、私はそれが簡単であると誤解されました。 とにかくそれを集めました。

何らかの理由で、PHP-FPM 7.1から始めました。 アイデアは、マルチステージビルドを使用することでした。 これを行うには、DockerfileのFROM



命令をFROM rnix/openssl-gost AS openssl-gost



、phpビルドの開始前にコンパイルされたopensslとcurlのコピーを登録し、ビルドオプションでこれらのライブラリへのパスを指定します--with-openssl-dir=/usr/local/ssl



および--with-curl=/usr/local/curl



は元のものを置き換えます。

驚きはどこからでも待っていました。 重要なものの1つは、php 7.1のビルド時にpkg-configが使用され、libcurl4-openssl-devの明示的なインストールが、libssl-devがパッケージのpkg-configで規定されていたことです。 結果は必要なものではありませんでした。 インストールを削除すると、pkg-configにopensslがないため、 /configure



phpがクラッシュしました。 カスタムのopensslとcurlアセンブリからlib/pkgconfig /*



を追加コピーする必要がありました。 数十のそのような驚きの後、アセンブリが行われ始めました。 さらに、依存関係がopensslによってインストールされ、それによって以前にコピーされたカスタムビルドのバイナリが上書きされることが判明しました。 最後に追加でコピーする必要がありました。 しかし、それだけではありません。

openssl_get_md_methods()



ハッシュアルゴリズムは、収集されたphpに現れました： GOST R 34.11-2012 with 256 bit hash



GOST R 34.11-2012 with 512 bit hash



GOST R 34.11-94



、 GOST R 34.11-94



これは、phpがGOSTエンジンに接続することを意味していました。 しかし、何らかの理由でphpでcurl拡張機能を使用すると、GOST-HTTPSを介してホストに接続して、そのようなアルゴリズムを知らなかったことがわかりました。 この理由を見つけるのに数時間費やしました。 ソース、PHPでのcurl拡張機能の動作、curl自体の動作、opensslとの通信方法を確認しました。 サポートされているアルゴリズムを決定したり、エンジンを接続したりする場所を探していました。 マスターブランチを検索し、グーグルで検索しましたが、すぐに問題を解決できるものは見つかりませんでした。 それから、PHPの最新バージョンではなく収集していることを思い出しました。

PHP-FPM 7.2をビルドしてみました。 元のDockerfile PHP-FPMを調整するために、スクリプトにいくつかの変更を加える必要がありましたが、アセンブリは驚くことなく動き始めました。 主なニュースは、php内のcurl拡張機能がGOSTアルゴリズムを使用してホストと通信できるようになったことですが、1つの迷惑がありました。 各php呼び出しは、 GOST engine already loaded



れているstdout GOST engine already loaded



ます。 とても不快です。 誰がこれを行ったのかすぐにはわかりませんでしたが、GOSTエンジンのソースにそのような行が見つかりました。 システムのどの部分でエラーが発生したかはまだわかりません：php、php-curl、curl、openssl。 しかし、どうやらphp 7.1ではphp-curlはエンジンをまったく接続しませんでしたが、php 7.2では2回接続を開始しました。 すべてが正常に機能したため、結論のみがあったので、Dockerfileの命令でソースを編集して削除することにしました。

 sed -i 's|printf("GOST engine already loaded\\n");|goto end;|' gost_eng.c
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

下にはすでにgoto end;



行がありますgoto end;



、だから真剣なことは何もしなかった。 しかし、動物園全体を再構築すると、すべてが望みどおりに機能し始めました。

PHP-FPM + OpenSSL + GOST + cURLを含む画像がDocker Hubで起動されました。

nginxでのGOST証明書のサポート

プログラミング言語で作業する能力はすでにたくさんありますが、さらに2つの可能性を望んでいました。

1. HTTPS（TLS）を介したGOST証明書でWebサーバーを簡単に昇格させます。
2. すべてのホストリクエストをGOST証明書で簡単にプロキシする

簡単-これは、Dockerイメージを意味します。 作成する必要があります。 これを行うには、DockerfileでカスタムOpenSSLとGOSTエンジンを使用してnginxをビルドする必要があります。 nginx アセンブリのドキュメントを開くと、sslに関するオプションが1つありました--with-http_ssl_module



、単なるブール値です。 しかし、nginxは人気のある製品であり、opensslを使用した構築手順が多数あるため、別のオプション--with-openssl=[DIR]



を見つけました。 実践が示しているように、nginxはopensslソースがここにあることを望んでおり、nginxスクリプトはアセンブリ自体を行います。 これは、私が望むものとはまったく異なります（マルチステージビルドを使用したかった）。 nginxコレクターのヘルプ出力に精通しましたが、そこで役立つものは見つかりませんでした。

OpenSSLソースのダウンロード、解凍、構成のGOSTエンジンを含むGOSTエンジンのビルドの手順を複製する必要がありました。 これはすべて収集され始めましたが、nginxではGOSTアルゴリズムのサポートはまだありませんでした。 ssl_ciphers GOST2001-GOST89-GOST89:HIGH:MEDIUM;



configでssl_ciphers GOST2001-GOST89-GOST89:HIGH:MEDIUM;



指定することでこれを確認しssl_ciphers GOST2001-GOST89-GOST89:HIGH:MEDIUM;



。 nginx -t



実行すると、このアルゴリズムを知らないと言いました。

結局のところ、nginxによってコンパイルされたopensslは動的エンジンをサポートしていませんでした。 ./Configure



no-dynamic-engine [forced]



ます。 ここで、OpenSSL アセンブリのドキュメントを注意深く読んで、何がforced



れたのかを調べる必要がありました。 その理由は、nginxが呼び出したopenssl ビルド引数 、つまりno-shared



見つかりました。 これが示されている場合、エンジンのロードのサポートを有効にするフラグはありません。 アセンブリ命令を編集する必要がありました。

 sed -i 's|--prefix=$ngx_prefix no-shared|--prefix=$ngx_prefix|' auto/lib/openssl/make
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これはすべて集まりましたが、nginxはgost.so



がパス/usr/lib/x86_64-linux-gnu/



に沿って見つからないことを誓い始めました。これはかなり奇妙です。同じopensslが完全に異なる場所でエンジンを検索して見つけるからです。彼が./lib/engines-1.1



に行っていた正確な場所。 組み立てられたエンジンを/usr/lib/x86_64-linux-gnu/



にコピーしてnginxを喜ばせる手順を追加しました。 稼いだ。

リポジトリのメインDockerfileの横に、 デモDockerfileを配置します。これは、アセンブリ中にGOST証明書を作成して使用し、 https： //gost.example.comで接続を処理します 。 1つのコンテナからこのデモに接続するには、DNSまたはドッカーネットワークを使用する必要がありますが、これについてはドキュメントで説明しました。

gost2001



でキーをgost2001



、その他のオプションはgost2012_256



、 gost2012_512



です。 そして、 GOST2001-GOST89-GOST89



- GOST2012-GOST8912-GOST8912



。

nginx + GOSTを含む画像がDocker Hubにアップロードされます ： https : //hub.docker.com/r/rnix/nginx-gost/

おわりに

LinuxシステムでGOSTアルゴリズムを使用する問題を研究し、ドッカーイメージの形式でソリューションを提供しました。すべてのドキュメントと例が付属しています。 このソリューションは、GitHubのリポジトリとして設計されています。

そのようなソリューションを使用することの安全性に言及する価値があります。 主なことは、たとえAutomated Build



がそこに記述されていても、Docker Hub上のイメージを信頼しないことです。 使用されているすべてのライブラリとシステムの編集で画像を収集し、任意のタグの下でDocker Hubにプッシュできます。 そのため、githubでリポジトリをフォークし、自分でだまして、アセンブリ中に疑わしい変更なしに公式のリソースのみが使用されているという事実があるかどうかをDockerfileの指示で確認して組み立てることをお勧めします。

自分で画像を収集することで、悪意のある編集がコードに含まれていないことを確認できます。アセンブリは誰でも閲覧できるオープンソースコードからのみ行われるためです。 ただし、これはエラーや脆弱性が含まれていないことを保証するものではありません。 独自の認定ツールを使用しても、エラーや脆弱性がないことを保証するものではありませんが、それらのコードもユーザーから閉鎖されます。

参照資料

1. GitHubのすべてのソリューションを含むリポジトリ
2. OpenSSL + GOST + cURLを使用したDocker Hubの画像
3. GOST R 34.10-2012ウィキペディアの認定ソリューションのリスト
4. GOSTエンジンリポジトリ
5. GOSTエンジンの機能と制限について
6. 実稼働環境で問題を解決する方法の例