DNSの次はHTTPとHTTPS
「60歳から始めるホワイトハッカーへの道」第6回です。
前回はDNSについて勉強しました。
MacBook Proから自分のブログ、
www.rails-fumiblog.comをdigで調べてみると、
www.rails-fumiblog.com ↓ DNS ↓ HerokuのDNS名 ↓ IPアドレスという流れを実際に確認できました。
ではDNSによって通信相手が分かった後、ブラウザとWebサーバーはどうやって会話しているのでしょう？
今回はHTTPとHTTPSについて勉強します。
そもそもHTTPとは？
普段Webサイトを見るとき、ブラウザとWebサーバーの間ではデータのやり取りが行われています。
そこで使われる通信の仕組みの一つがHTTP（Hypertext Transfer Protocol）です。
簡単に考えると、
ブラウザ ↓ 「このページをください」 ↓ Webサーバー Webサーバー ↓ 「はい、どうぞ」 ↓ ブラウザというやり取りです。
Railsを5年間使ってきた私には、ここで見覚えのある言葉が出てきます。
GET POSTRailsのroutes.rbでも何度も使ってきました。
今までRailsの機能として見ていたGETやPOSTも、HTTPの勉強につながってくるわけです。
ではHTTPSの「S」は何？
私のブログを見ると、
https://www.rails-fumiblog.comとなっています。
HTTPではなくHTTPSです。
HTTPSではTLSという仕組みを利用して通信を保護します。
これによって、ブラウザとWebサイトの間でやり取りされる通信について、盗み見や改ざんなどのリスクを減らすことができます。
ログインIDやパスワードなどを扱うWebアプリでは特に重要な仕組みです。
第3回では、
HTTP → 80番 HTTPS → 443番という代表的なポート番号も勉強しました。
また一つ、以前勉強した内容とつながりました。
curlで自分のブログを調べてみる
今回も説明を読むだけではなく、自分のMacBook Proで実験します。
ターミナルを開いて、
curl -I https://www.rails-fumiblog.comを実行してみます。
curlはURLを指定して通信できるコマンドです。
今回付けている-Iオプションでは、ページ本文ではなくHTTPのレスポンスヘッダーを確認できます。
普段ブラウザではWebページしか見ていませんが、その裏側ではWebサーバーからさまざまな情報が返されています。
「200 OK」って何だ？
実行結果の最初の方に、
HTTP/2 200あるいは環境によって、
HTTP/1.1 200 OKのような表示が出るかもしれません。
この200はHTTPステータスコードです。
200は、リクエストが正常に処理されたことを表します。
Railsを開発しているとログの中で、
Completed 200 OKという表示を何度も見てきました。
今まで「正常に表示されたんだな」くらいに思っていましたが、これもHTTPの仕組みだったんですね。
301や302も見たことがある
HTTPステータスコードには200以外にもいろいろあります。
200 → 成功301 → 恒久的なリダイレクト 302 → 一時的なリダイレクト 404 → ページが見つからない 500 → サーバー側のエラー404や500なら、Webサイトを使っているだけでも見たことがあります。
Railsを使っていると、もっと見覚えがあります（笑）。
エラーが出たときは嫌な数字でしたが、HTTPを勉強してみると、それぞれにちゃんと意味があることが分かります。
HTTPヘッダーを見てみる
curlの結果を見ると、ステータスコード以外にもたくさんの情報が表示されます。
これがHTTPヘッダーです。
HTTPヘッダーは、クライアントとサーバーが通信するときに追加情報を渡すために使われます。
例えば環境によっては、
content-type: content-length: location: cache-control: set-cookie: strict-transport-security:などを見ることがあります。
ただし、実際にどのヘッダーが返るかはWebサイトの設定によって違います。
今は全部覚える必要はありません。
まずは、
「Webページを開くとHTMLだけが返ってくるわけではない」
ということを覚えておきます。
HTTPでアクセスしたらどうなる？
次に少し実験してみます。
curl -I http://www.rails-fumiblog.com先ほどはhttps://でしたが、今回はhttp://です。
もしHTTPからHTTPSへのリダイレクトが設定されていれば、
301などのリダイレクトを示すステータスと、
location: https://...のような情報が返ってくることがあります。
ここは自分のブログで実際にどんな結果になるのか確認してみたいところです。
HTTPSなら絶対安全なの？
ここで注意したいことがあります。
HTTPSになっているからといって、そのWebサイトの内容そのものが必ず安全だという意味ではありません。
HTTPSは通信経路をTLSによって保護する仕組みです。
例えば偽サイト自体がHTTPSを使うこともできます。
そのため、
HTTPSだから安全なサイトと単純に判断するのではなく、
HTTPS ＝ ブラウザと接続先との通信が保護されていると理解した方がよさそうです。
Railsで使っていたものが全部つながってきた
今回まで勉強した内容を、自分のRailsブログを例に並べてみます。
www.rails-fumiblog.com ↓ DNSで名前を調べる ↓ 通信先が分かる ↓ TCP/IPで通信 ↓ HTTPS 443番ポート ↓ HTTPリクエスト ↓ Heroku ↓ Rails ↓ HTTPレスポンス ↓ ブラウザにページが表示される普段ブラウザにURLを入力すると一瞬でブログが表示されます。
でも、その裏側ではこれだけいろいろな仕組みが関係しています。
5年間Railsを使ってきましたが、セキュリティの勉強を始めたことで、Railsの外側で何が起きているのかも少しずつ見えてきました。
今回覚えたこと
- HTTPはWebで情報をやり取りするためのプロトコル
- HTTPSではTLSを利用して通信を保護する
- HTTPでは80番、HTTPSでは443番が代表的なポート番号
- curlを使うとMacのターミナルからHTTP通信を確認できる
- 200や404、500などはHTTPステータスコード
- HTTPヘッダーには通信に関する追加情報が入っている
- HTTPSだからWebサイトの内容まで必ず安全という意味ではない
次回はGETとPOSTを調べてみる
今回、HTTPを調べているとGETという言葉が出てきました。
これはRailsを使っている私には非常になじみがあります。
get post patch put deleteroutes.rbで何度書いたか分かりません。
でも、
「GETとPOSTの違いをHTTPから説明してください」
と言われると……。
ちょっと怪しい（笑）。
次回は「GETとPOSTとは？Railsのroutes.rbからHTTPメソッドを理解する」をテーマに、自分のRailsアプリを教材にして調べてみます。