Lycolog

WSL上のUbuntuで動作するnginxでHTTPSに対応したサーバーを作る方法。実機でも同様の手順でいける

確認環境

手順

1. Windows側にmkcertを入れる
2. mkcertで証明書を作る
   • mkcert sandbox.test
3. 以下のpemファイルが生成される
   • sandbox.test.pem
   • sandbox.test-key.pem
4. 生成されたpemファイルを/etc/nginx/conf.d/ssl/に移動する

5. /etc/nginx/conf.d/sandbox.test.confを作成し、以下のような記述をする

   server {
       listen       443 ssl;
       client_max_body_size 100m;
       server_name  sandbox.test;
   
       ssl_certificate     conf.d/ssl/sandbox.test+1.pem;
       ssl_certificate_key conf.d/ssl/sandbox.test+1-key.pem;
   
       access_log   /var/log/nginx/sandbox.access.log;
       error_log    /var/log/nginx/sandbox.error.log;
   
       # ファイルホスト用
       #  location / {
       #    root /usr/share/nginx/html/sandbox;
       #    index index.html;
       #    try_files $uri /index.html =404;
       #  }
   
       # APサーバーへのリバプロ用
       location ~ ^/.*$ {
           rewrite ^/.*$ / break;
           proxy_set_header X-Request-Path $request_uri;
           proxy_set_header X-Host $host;
           proxy_pass  http://127.0.0.1:9999;
       }
   
       # fastcgi用
       location ~ \.php$ {
           root  /usr/share/nginx/html/sandbox;
           fastcgi_pass unix:/run/php/php8.0-fpm.sock;
           fastcgi_index index.php;
           include fastcgi_params;
           fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
       }
   }
   

6. nginxを再起動する
   • sudo service nginx restart

他の端末に証明書を撒く方法

mkcertのRoot CAをエクスポートして他の端末に突っ込めば、他の端末でもpemが流用できる

• mkcertで作ったCA証明書をエクスポートする方法
• mkcertで作ったCA証明書をインポートする方法

mkcertで作ったCA証明書をエクスポートする方法でエクスポートしたCA証明書を他の端末に取り込む方法

• Android
  • 確認環境
  • 手順
• Windows
  • 確認環境
  • 手順
• Ubuntu
  • 確認環境
  • 手順

Android

確認環境

Galaxy S22 Ultra Android 14

手順

1. Android端末のストレージにエクスポートしたCA証明書を持ってくる
2. 設定＞セキュリティ＞その他のセキュリティ設定＞ストレージからインストール＞CA証明書＞このままインストール
3. 内部ストレージからエクスポートしたCA証明書を選択

Windows

確認環境

Windows 11 Pro (22621.3155)

手順

1. スタートメニューやコンパネから「ユーザー証明書の管理」を開く
2. 信頼されたルート証明書を右クリックし、すべてのタスク＞インポート
   

   

3. エクスポートしたCA証明書を参照する
   

   

4. 証明書ストアが「信頼されたルート証明機関」になっていることを確認する
   

   

5. 取り込む証明書が正しいことを確認して「はい」
   

   

Ubuntu

確認環境

Ubuntu 22.04.3 LTS

手順

$CER_FILE="エクスポートしたCA証明書"
sudo openssl x509 -inform der -outform pem -in $CER_FILE -out PEM.crt
sudo cp PEM.crt /usr/local/share/ca-certificates
sudo update-ca-certificates

別の端末に持っていきたいときに使える

確認環境

手順

1. ユーザー証明書の管理を開く
2. 信頼されたルート証明機関＞証明書
3. mkcertで始まる証明書を探す
4. 右クリック＞すべてのタスク＞エクスポート
5. DER encoded binary X.509 (.CER)
6. 適当なファイル名を付けてエクスポート

ここ最近なりすましメールが目立つのでなりすましメール防御対策を取りましょうという話。

なりすましメールが増えている一例

ここ数日の間にイラストレーターのIxy先生やMastodonインスタンス管理人のにょき氏といった一定の知名度を持つ人物を中心になりすましメールの被害にあっているようだ。

• https://twitter.com/Ixy/status/1758319986790309890
• https://v2.nyoki.club/@nyoki/111944227667077349

ここまで目立つのは余り見聞きしなかったので恐らくここ昨今のGMailとかの騒動を見たところで、なりすましメールを作れることに気づいた人物が愉快犯的に行為をしているのだろう。

取りうる防御策

個人レベルでできる対策としてはDNSレコードやメールサーバーの設定にSPF, DKIM, DMARCを設定することだ。これらの内容についてはGoogleによるDMARC を使用してなりすましと迷惑メールを防止するが詳しい。

さくらのレンタルサーバーを利用している場合は以下が参考になる。

• SPFレコードを設定したい
• DKIM署名、DMARCを設定したい

さくらのレンタルサーバーを利用して外部DNSを利用している場合は、私が以前書いたValue-DomainのドメインをさくらのレンタルサーバーのメールでSPF, DKIM, DMARC対応させるが参考になるだろう。

SPD, DKIM, DMARCの三点を設定することで相手のメールサーバーがこれらに対応している場合になりすましメールを迷惑メールとして分類したり、メールの受信を拒否できるとされているため、設定することでなりすましメールを防御できる可能性が高まる。

メール送信に使っていないドメインに関しても以下のようなDMARCを設定しておくことで、悪意のある第三者によるなりすましを防げるだろう。

txt _dmarc v=DMARC1; p=reject; aspf=r; adkim=r

またメールサーバーを運用されている各位におかれては、SPD, DKIM, DMARCの三点を識別し、適切に受信メールをフィルタリングできる仕組みを導入して頂けると犯罪予告や迷惑メールによる被害を減らせる可能性があるので、是非とも導入を検討いただきたい。

前職で古いWebシステムのマイグレーションしてた時に思ったのだが、SameSite CookieがあればCSRF Tokenは最早いらないのではないか？というのに気が付いたので調べてみた話。

結論として言うとEdgeではPOSTリクエストでCookieが飛ぶ事はないので、CSRF Tokenを考慮する必要はなさそうに思える。

理由としてはCookieでSameSite=strictを指定している場合、クロスドメインでのCookie送信がブロックされるという話が事実であればCSRF Tokenは不要であるはずだからだ。

これによって悪意のあるサイトからAjaxやリダイレクト、フォームなどを使った攻撃をした場合にサーバーにCookieが送信されなくなる筈なので、理論上は問題なくなる。

以下では実際にCookieが送信されるかどうかの動きを見てみた。確認環境はMicrosoft Edge 121.0.2277.83。方式のリンクはシーケンス図になっている。

シーケンス図に書いてあるSameSite={var}の{var}にはstrict、laxが入る。確認内容としてはシーケンスの一番最後のHTTPリクエストでCookieが送信されているかどうかを見ている。noneは面倒なので見ていない。

SameSite=strictだと外部サイトから開いたときにCookieが送信されないため、Google検索などから流入された時のログイン状態に不都合が出ると思われるので、その様なケースではSameSite=laxが無難だろう。

SameSite=laxの場合、GETリクエストではCookieが送信されるため、CSRF攻撃を受ける可能性があるが、GETで更新系処理をしない限り基本は問題にならないと思われる。

参考

• 2022年1月においてCSRF未対策のサイトはどの条件で被害を受けるか | 徳丸浩の日記
• Cookies: HTTP State Management Mechanism (httpwg.org)
  • httpwgによるドラフトの仕様（ブラウザがこれを守るかどうかはまた別の話）