HTTP/2 対応に必要な条件
私のCloud9環境はほぼ全て対応済だったのでだいぶ楽でした。
これからの時代はAWSですね。
Apache Ver 2.4.17以上であること
$ httpd -v
Server version: Apache/2.4.41 (Amazon)
Server built: Oct 15 2019 22:21:35
OpenSSL Ver 1.0.2以上であること
$ openssl version
OpenSSL 1.0.2k-fips 26 Jan 2017
mod_http2をインストールしていること
$ httpd -M | grep http2
http2_module (shared)
$ less /etc/httpd/conf.modules.d/00-base.conf | grep 'mod_http2'
LoadModule http2_module modules/mod_http2.so
SSL対応していること(任意?)
こちら私の環境は未対応でした。
このためだけにRoute53でドメイン取得したりすんのはだるいので、
オレオレ証明書で対応することにしました。
以下の記事に書いてある通りに進めれば、
特にトラブルもなく対応できました。
もしかすると、SSL対応しなくても
HTTP/2対応できるかもしれませんが試してません。
特筆すべき点
私の環境はmod_sslをインストールしてなかったみたいなので、
yumでインストールしました
sudo yum install mod24_ssl.x86_64
上のモジュールをインストールし、オレオレ証明書でSSL対応して、
curlコマンドでHTTP/2になったかを確認してみたところ、
なってませんでした。
理想
curl -I --http2 --insecure https://XX.XXX.XXX.XX/
HTTP/2 200 <-- これが出るはず
現実
curl -I --http2 --insecure https://XX.XXX.XXX.XX/
HTTP/1.1 200 <-- あれ～～？？
「mpmでpreforkモジュールが設定されているとHTTP2が無効化される」らしいです。
自分でも何を言っているのかわかりません。ごめんなさい。
とりあえず以下のサイトにある通り、
00-mpm.conf から mpm_prefork_module をコメントアウトし、
mpm_event_module を有効化して、Apache再起動したらHTTP/2で読み込まれました。
$ sudo vi /etc/httpd/conf.modules.d/00-mpm.conf
#LoadModule mpm_prefork_module modules/mod_mpm_prefork.so
LoadModule mpm_event_module modules/mod_mpm_event.so
動作確認
curlコマンドを叩くことで確認できます。
私の環境はオレオレ証明書を使っているので --insecure オプションが必要です
curl -I --insecure --http2 https://XX.XXX.XXX.XX
HTTP/2 200
あるいは、ブラウザからでも簡単に確認することもできます
なぜ対応したのか？
Burp Suiteを用いて自分の開発環境で脆弱性診断を実施したところ、
「HTTPリクエストスマグリング」という脆弱性があることがわかったからです。
- HTTPリクエストスマグリングとは
- https://qiita.com/shoooooo/items/45899d4b4ccfd095f8c8
- https://www.scutum.jp/information/waf_tech_blog/2018/11/waf-blog-059.html
そして、その解決策は
「通信プロトコルをHTTP/1.1からHTTP/2にアップグレードすることである」
と書いてあったので、そうした次第です
BurpSuiteに書いてあった文章を翻訳したものを下記します。
問題の背景
HTTP リクエストの密輸の脆弱性は、
ウェブサイトが HTTP のパースが一貫していないウェブサーバを介して
HTTP リクエストをルーティングするときに発生します。
異なるサーバによって異なる長さと解釈されるリクエストを提供することで、
攻撃者はバックエンドの TCP/TLS ソケットを毒し、
次のリクエストに任意のデータを追加することができます。
ウェブサイトの機能にもよりますが、
フロントエンドのセキュリティルールを迂回したり、
内部システムにアクセスしたり、
ウェブキャッシュを毒したり、
サイトを積極的に閲覧しているユーザーに対して
様々な攻撃を仕掛けたりすることができます。
問題の修正
この脆弱性のすべてのバリエーションを解決するには、
フロントエンドサーバがバックエンドシステムとの通信に
HTTP/2 を排他的に使用するように設定するか、
バックエンド接続の再利用を完全に無効にする必要があります。
あるいは、チェーン内のすべてのサーバが同じ設定で
同じウェブサーバソフトウェアを実行していることを確認することもできます。
この脆弱性の特定のインスタンスは、
フロントエンドサーバを再設定して
曖昧なリクエストを正常化してからルーティングするか、
バックエンドサーバが曖昧なリクエストに遭遇したときに
メッセージを拒否して接続を閉じるように設定することで解決できます。
コマンド履歴
未来の自分のために、どんなコマンドを叩いたのかを記します
openssl version
yum list installed | grep openssl
httpd -v
sudo cp /etc/httpd/conf/httpd.conf /etc/httpd/conf/httpd.conf.bak
sudo vi /etc/httpd/conf/httpd.conf
sudo service httpd restart
httpd -M | grep http2
less /etc/httpd/conf.modules.d/00-base.conf | grep 'mod_http2'
ls -l /etc/httpd/modules/ | grep ssl
sudo yum list available | grep ssl
sudo yum install mod24_ssl.x86_64
ls -l /etc/httpd/modules/ | grep ssl
mkdir ~/ssl
cd ~/ssl
openssl genrsa -out ca.key 2048
openssl req -new -key ca.key -out ca.csr
openssl x509 -req -days 365 -in ca.csr -signkey ca.key -out ca.crt
sudo cp -p ca.crt /etc/pki/tls/certs/
sudo cp -p ca.key /etc/pki/tls/private/
sudo cp -p ca.csr /etc/pki/tls/private/
restorecon -RvF /etc/pki/
sudo cp /etc/httpd/conf.d/ssl.conf /etc/httpd/conf.d/ssl.conf.bak
sudo vi /etc/httpd/conf.d/ssl.conf
sudo service httpd restart
curl -I --insecure --http2 https://XX.XXX.XXX.XX
sudo less /etc/httpd/logs/error_log
sudo cp /etc/httpd/conf.modules.d/00-mpm.conf /etc/httpd/conf.modules.d/00-mpm.conf.bak
sudo vi /etc/httpd/conf.modules.d/00-mpm.conf
sudo service httpd restart
history