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