アカウント名:
パスワード:
httpでアクセスできないなら問題ない?
仮に、全てのブラウザが HTTP Strict Transport Security (HSTS) [ietf.org] (RFC 6797) をサポートしているのならば、Cookie に secure 属性を付ける必要は無いでしょう(Strict Transport Security を有効化した場合)。パケットの改ざんが可能な状況下においては、http 接続のページについては正規の URI で偽ページを表示させることが可能な訳なので、当該ドメインにそもそも http で接続できないようにした方が、より安全です。
ただし、現状では、HSTS をサポートしている主要ブラウザ [mozilla.org] は、Firefox と Chrome と Opera のみで、Internet Explorer と Safari はサポートしていません。従って、現状では HSTS と Cookie の secure 属性を併用するのが望ましいでしょう。
> 当該ドメインにそもそも http で接続できないようにした方が、より安全です。
それは意味ない。MITMされるだけ。サーバで何をやっても無駄だと理解すべし。
HSTS ならば、初回の接続で MITM されない限り (または expireTime が経過したり、クライアントのブラウザの Strict Transport Security の保存データが削除されたりしない限り)、MITM を防ぐことができます。
「今後このドメインに対して http での接続を禁止する」 という情報をブラウザに記録する仕組みですので、当該ドメインへの接続に際して MITM されたとしても http 接続は成立しません。
初回の接続で MITM されるって話だろ。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私は悩みをリストアップし始めたが、そのあまりの長さにいやけがさし、何も考えないことにした。-- Robert C. Pike
httpで (スコア:0)
httpでアクセスできないなら問題ない?
Re:httpで (スコア:2)
仮に、全てのブラウザが HTTP Strict Transport Security (HSTS) [ietf.org] (RFC 6797) をサポートしているのならば、Cookie に secure 属性を付ける必要は無いでしょう(Strict Transport Security を有効化した場合)。パケットの改ざんが可能な状況下においては、http 接続のページについては正規の URI で偽ページを表示させることが可能な訳なので、当該ドメインにそもそも http で接続できないようにした方が、より安全です。
ただし、現状では、HSTS をサポートしている主要ブラウザ [mozilla.org] は、Firefox と Chrome と Opera のみで、Internet Explorer と Safari はサポートしていません。従って、現状では HSTS と Cookie の secure 属性を併用するのが望ましいでしょう。
Re: (スコア:0)
> 当該ドメインにそもそも http で接続できないようにした方が、より安全です。
それは意味ない。MITMされるだけ。サーバで何をやっても無駄だと理解すべし。
Re:httpで (スコア:2)
HSTS ならば、初回の接続で MITM されない限り (または expireTime が経過したり、クライアントのブラウザの Strict Transport Security の保存データが削除されたりしない限り)、MITM を防ぐことができます。
「今後このドメインに対して http での接続を禁止する」 という情報をブラウザに記録する仕組みですので、当該ドメインへの接続に際して MITM されたとしても http 接続は成立しません。
Re: (スコア:0)
初回の接続で MITM されるって話だろ。