- PR -

ＳＳＬでＨＴＴＰメッセージはどの部分が暗号化されるの？

参照元記事 | 同じ記事を参照しているスレッド一覧
1
投稿者投稿内容
hrfujiwa
会議室デビュー日: 2002/08/28
投稿数: 2
投稿日時: 2002-08-28 11:55
「Javaを紐解くための重点キーワード」の”Java Servlet（サーブレット）”（http://www.atmarkit.co.jp/fjava/keyword/jkey/jkey01.html）の
”セッション管理”の”JSP、Servletを使ったセッション管理”に
HTTPプロトコルを、インターネット上で電子商取引に使うとき、暗号化が必要である。これには多くの場合SSLという暗号化技術が使われる。SSLはHTTPプロトコルの本文部分を暗号化する。HTTPリクエストの本文には、POST方式で作られたパラメータやクッキー情報が入る。GET方式でパラメータ渡しをする場合や、URL再書き込みによるセッションIDなどは、この暗号化に含まれない。このため、ネットワーク・トレースなどによるのぞき見行為に対して、URL再書き込みによるセッションIDは無防備であるといえる。SSLを使ったサイトを構築するためには、GET方式やURL再書き込みは向いていないということである。
とあります。
SSLにおいてHandshake（SSLのセッション確立）が完了した後のクライアント（ブラウザ）とサーバ（Ｗｅｂサーバ）間の電文はすべて暗号化されると認識していますが違うのでしょうか。ＨＴＴＰメッセージのメッセージボディのみが暗号化される（メッセージヘッダは暗号化されない）という事でしょうか。どなたか教えて頂けないでしょうか。
yuzy
大ベテラン
会議室デビュー日: 2002/02/14
投稿数: 117
投稿日時: 2002-08-28 18:38
>SSLにおいてHandshake（SSLのセッション確立）が完了した後のクライアント（ブラウザ）とサーバ
>（Ｗｅｂサーバ）間の電文はすべて暗号化されると認識していますが違うのでしょうか。

私もこのように認識していました。


>ＨＴＴＰメッセージのメッセージボディのみが暗号化される（メッセージヘッダは暗号化されない）という事でしょうか。どなたか教えて頂けないでしょうか。

試しに Linux の tcpdump で通信内容を capture してみましたが、
GET .... という部分まで暗号されているように見受けられます。
（きちんとした回答でなくて申し訳ないですが）
t-wata
大ベテラン
会議室デビュー日: 2002/07/12
投稿数: 209
お住まい・勤務地: 東京
投稿日時: 2002-08-28 19:57
ボディだけです。その証拠にProxyを通さなきゃならない環境でもHTTPSを使えます。
H2
ぬし
会議室デビュー日: 2001/09/06
投稿数: 586
お住まい・勤務地: 港
投稿日時: 2002-08-28 20:23
> ボディだけです。その証拠にProxyを通さなきゃならない環境でもHTTPSを使えます。
??? Proxyが見るのはIPヘッダではないですか？HTTP・HTTPS内のメッセージヘッダはProxyには必要ないものではないでしょうか。（とは言いつつもネットワークの専門ではないので自信はありません。間違えていたらごめんなさい）

Netscape社のSSL関連のドキュメントを見ると
（ http://developer.netscape.com/docs/manuals/security/sslin/index.htm ）
引用:

An encrypted SSL connection requires all information sent between a client and a server to be encrypted by the sending software and decrypted by the receiving software, thus providing a high degree of confidentiality.

って書いてあります。Getのヘッダもinformationの一部なので暗号化されるのではないでしょうか？（あまり自信ないのですが…）
まりり
ぬし
会議室デビュー日: 2001/12/05
投稿数: 329
投稿日時: 2002-08-28 22:42
私も調べてみました。
SSLってセッション層のプロトコルなんですね。勘違いしてました。

http://wp.netscape.com/eng/ssl3/draft302.txt より抜粋。
引用:

5.7 Application data protocol

Application data messages are carried by the Record Layer and are
fragmented, compressed and encrypted based on the current
connection state. The messages are treated as transparent data to
the record layer.


ということで、HTTPのヘッダもボディも暗号化なりのセキュリティを得られそうです。


ただ、引用もとの「GETを使うな」という趣旨は昔からよく言われており、
HTTP Proxyを通した際のログなどにURLの一部として記録されてしまったりと
セキュリティ的には薦められたものではないのは確かではないでしょうか。


私の理解ではProxyは各プロトコルごとに必要であって、IPヘッダだけを見ている
わけではないと思いますが・・・（自信はありません）
HTTPSが通るのはたまたまHTTP/HTTPSに対応してるだけだと思うのですが。
hrfujiwa
会議室デビュー日: 2002/08/28
投稿数: 2
投稿日時: 2002-08-29 09:35
ご回答　ありがとうございました。
暗号化されるようですね。
＠ＩＴ内の各種資料を読みますと、ソース表示をするとパラメータの値が見える等など
の理由でＧＥＴではなくＰＯＳＴで行うのが良いとわかりました。
omatsu
常連さん
会議室デビュー日: 2002/08/29
投稿数: 20
投稿日時: 2002-08-29 11:03
引用:

t-wataさんの書き込み (2002-08-28 19:57) より:
ボディだけです。その証拠にProxyを通さなきゃならない環境でもHTTPSを使えます。


これは、ちょっと違うのでコメントさせてください。
SSL のproxy は、SSLトンネリングと呼ばれる手法で実現されています。
この場合、proxy は SSL セッションの中身は右から左に丸投げするだけで何も見てません。

ブラウザから、"https://somewhere.com/somewhat?param=hoge" を見ようとした時、
ブラウザから proxy には、
コード:
CONNECT somewhere.com:443 HTTP/1.1

のコマンドを投げ、proxy は、somewhere.com:443 とのセッションを張りに行って確立すると、あとは、ブラウザと somewhere.comとの間にいて、中身は何も見ず、受け渡しの仲介をしているだけです。
HTTPヘッダの中身はおろか、SSL 通信であるかどうかすら、proxy にとっては、どうでもよく、また、うかがい知れる話でもありません。

そういう意味では、「proxy でも通るからヘッダは暗号化されていないはずだ」という理屈は成り立ちません。実際、他の人もおっしゃっているとおり、暗号化されているはずです。

また、SSLトンネリングの場合、上記のように、proxy に伝わる情報は、あて先サーバとポート番号のみなので、GET メソッドであっても、そのパラメタの内容は proxy にはわかりませんので、proxy 上のログにも残らないはずです。（というか、GETメソッドかどうかすら、もっと言えば、HTTPSかどうかすら、proxy は知りようがない)
ただ、クライアント上の履歴には、やはり残るでしょうから、依然として、セキュリティ上奨められないとは思います。

ご参照: ftp://ftp.isi.edu/in-notes/rfc2817.txt Upgrading to TLS Within HTTP/1.1
t-wata
大ベテラン
会議室デビュー日: 2002/07/12
投稿数: 209
お住まい・勤務地: 東京
投稿日時: 2002-08-30 17:40
>「proxy でも通るからヘッダは暗号化されていないはずだ」という理屈は成り立ちません。

ですね。間違ってました。HTTPSの場合は、HTTPの場合と異なり、proxyはトンネリングするようですね。

ご指摘有難うございました。
1

スキルアップ／キャリアアップ（JOB@IT）