QA@IT
«回答へ戻る

200
 まだ出てくるかもしれませんが、今気になったのはこの辺です。
 
 ======================================
-コメントを受けて追記。
+コメントを受けて追記。(2013/09/02 21:00)
 >一度アクセスされたら以後はステータスコード304を返しています。
 
 真っ当なクライアントが常に一番最初に来ることは保障できないのでは?
 ここにあるようにCAであること=無条件に信頼されることであり、信用を維持するのにコストがかかるから証明書の値段に跳ね返ってきているわけで。
 サーバ証明書の代わりにScript URLをCAがサーバに対して発行する訳で、よくよく考えてみると少々形の変わったSSLになってるだけのようにも思えてきました。
 CAはScript URLを通じて、サーバの実在証明(クライアントがまさにアクセスしようとしている本物である証明)をしているんですよね?
+
+=========================================
+さらに追記。(2013/09/03 10:00)
+ごちゃごちゃになってきてすいません。。。
+
+改めてよく考えてみたらMIM攻撃は成功しないのかな。
+Script URL盗聴してcommon keyをクライアントより先に取得しても、そのカギは使われないし。
+(クライアントは使用済みScript URLでアクセスするのでcommon keyをもらうことができず、最初からやり直し)
+
+ただ、CAはServeに対して何らかの認証を行っているわけではない場合は、そもそも根本的に暗号化通信の意味をなしていないと考えます。
+CAは単にWebサービスとして待ちうけていて、サーバとクライアントにSSL上で共通鍵を交換できる仕組みを提供するのみで、相手が誰であるかを保証していない場合。

よく考えてあるなーとは思うのですが、いくつか疑問点。

  • CAは、サーバとクライアントのペアをどうやって識別するのでしょうか?
    Script URLと言うのがこのための識別子のように思うのですが、これは実際にはセッションIDなどを含む、クライアントを識別できるような厳格な識別子になるのかな?

  • Script URLは盗聴可能ではないでしょうか?
    Return HTMLでクライアントはサーバからScript URLを受信し、これを使用してCAへcommon keyを取得しに行くように見えます。
    これって盗聴可能ではないでしょうか?
    Script URLはある意味暗号化通信の秘密鍵であるcommon keyに準ずる秘密情報だと思うのですが、第三者がこれを取得してCAに問い合わせれば、秘密鍵ゲットできそうな。
    盗聴されても平気な仕組みになっていれば話は変わってきますけれど。

  • 暗号化方式は固定でしょうか?
    SSLではSSLセッション確立時に、サーバとクライアント間で手持ちの使用可能な暗号化方式を提示し、相談の上どれを使うか決定しています。このプロセスが存在しませんが、AES固定でしょうか?もしそうだとUAが限定されたり、将来性に難がありそうです。

まだ出てくるかもしれませんが、今気になったのはこの辺です。

======================================
コメントを受けて追記。(2013/09/02 21:00)

一度アクセスされたら以後はステータスコード304を返しています。

真っ当なクライアントが常に一番最初に来ることは保障できないのでは?
例えば無線LANルータやプロキシが盗聴者だった場合などは、Man In The Middle攻撃が成功しませんか?
また、ネットワーク遅延なり瞬断なりでUAが正常にCAからcommon keyを取得できなかった場合にリトライできませんが、最初のフローからやり直しなんでしょうか。

あと、AES固定で行くとして、このSHTTPが普及期に入った5年後あたりには脆弱な暗号化方式になっている可能性は結構ありそうな気がしています。

根本的な話ですが、Open SHTTP CAは従来のCAの証明書発行能力に加えてサーバやクライアントからのリクエストを捌く能力がさらに必要になるようなんですが、現状のSSLより安価になるんでしょうか。

http://qiita.com/kawaz/items/f90810b9ea823b6556a8

ここにあるようにCAであること=無条件に信頼されることであり、信用を維持するのにコストがかかるから証明書の値段に跳ね返ってきているわけで。
サーバ証明書の代わりにScript URLをCAがサーバに対して発行する訳で、よくよく考えてみると少々形の変わったSSLになってるだけのようにも思えてきました。
CAはScript URLを通じて、サーバの実在証明(クライアントがまさにアクセスしようとしている本物である証明)をしているんですよね?

=========================================
さらに追記。(2013/09/03 10:00)
ごちゃごちゃになってきてすいません。。。

改めてよく考えてみたらMIM攻撃は成功しないのかな。
Script URL盗聴してcommon keyをクライアントより先に取得しても、そのカギは使われないし。
(クライアントは使用済みScript URLでアクセスするのでcommon keyをもらうことができず、最初からやり直し)

ただ、CAはServeに対して何らかの認証を行っているわけではない場合は、そもそも根本的に暗号化通信の意味をなしていないと考えます。
CAは単にWebサービスとして待ちうけていて、サーバとクライアントにSSL上で共通鍵を交換できる仕組みを提供するのみで、相手が誰であるかを保証していない場合。

よく考えてあるなーとは思うのですが、いくつか疑問点。

* CAは、サーバとクライアントのペアをどうやって識別するのでしょうか?
Script URLと言うのがこのための識別子のように思うのですが、これは実際にはセッションIDなどを含む、クライアントを識別できるような厳格な識別子になるのかな?

* Script URLは盗聴可能ではないでしょうか?
Return HTMLでクライアントはサーバからScript URLを受信し、これを使用してCAへcommon keyを取得しに行くように見えます。
これって盗聴可能ではないでしょうか?
Script URLはある意味暗号化通信の秘密鍵であるcommon keyに準ずる秘密情報だと思うのですが、第三者がこれを取得してCAに問い合わせれば、秘密鍵ゲットできそうな。
盗聴されても平気な仕組みになっていれば話は変わってきますけれど。

* 暗号化方式は固定でしょうか?
SSLではSSLセッション確立時に、サーバとクライアント間で手持ちの使用可能な暗号化方式を提示し、相談の上どれを使うか決定しています。このプロセスが存在しませんが、AES固定でしょうか?もしそうだとUAが限定されたり、将来性に難がありそうです。

まだ出てくるかもしれませんが、今気になったのはこの辺です。

======================================
コメントを受けて追記。(2013/09/02 21:00)
>一度アクセスされたら以後はステータスコード304を返しています。

真っ当なクライアントが常に一番最初に来ることは保障できないのでは?
例えば無線LANルータやプロキシが盗聴者だった場合などは、Man In The Middle攻撃が成功しませんか?
また、ネットワーク遅延なり瞬断なりでUAが正常にCAからcommon keyを取得できなかった場合にリトライできませんが、最初のフローからやり直しなんでしょうか。

あと、AES固定で行くとして、このSHTTPが普及期に入った5年後あたりには脆弱な暗号化方式になっている可能性は結構ありそうな気がしています。


根本的な話ですが、Open SHTTP CAは従来のCAの証明書発行能力に加えてサーバやクライアントからのリクエストを捌く能力がさらに必要になるようなんですが、現状のSSLより安価になるんでしょうか。

http://qiita.com/kawaz/items/f90810b9ea823b6556a8

ここにあるようにCAであること=無条件に信頼されることであり、信用を維持するのにコストがかかるから証明書の値段に跳ね返ってきているわけで。
サーバ証明書の代わりにScript URLをCAがサーバに対して発行する訳で、よくよく考えてみると少々形の変わったSSLになってるだけのようにも思えてきました。
CAはScript URLを通じて、サーバの実在証明(クライアントがまさにアクセスしようとしている本物である証明)をしているんですよね?

=========================================
さらに追記。(2013/09/03 10:00)
ごちゃごちゃになってきてすいません。。。

改めてよく考えてみたらMIM攻撃は成功しないのかな。
Script URL盗聴してcommon keyをクライアントより先に取得しても、そのカギは使われないし。
(クライアントは使用済みScript URLでアクセスするのでcommon keyをもらうことができず、最初からやり直し)

ただ、CAはServeに対して何らかの認証を行っているわけではない場合は、そもそも根本的に暗号化通信の意味をなしていないと考えます。
CAは単にWebサービスとして待ちうけていて、サーバとクライアントにSSL上で共通鍵を交換できる仕組みを提供するのみで、相手が誰であるかを保証していない場合。

200
 http://qiita.com/kawaz/items/f90810b9ea823b6556a8
 
 ここにあるようにCAであること=無条件に信頼されることであり、信用を維持するのにコストがかかるから証明書の値段に跳ね返ってきているわけで。
+サーバ証明書の代わりにScript URLをCAがサーバに対して発行する訳で、よくよく考えてみると少々形の変わったSSLになってるだけのようにも思えてきました。
+CAはScript URLを通じて、サーバの実在証明(クライアントがまさにアクセスしようとしている本物である証明)をしているんですよね?

よく考えてあるなーとは思うのですが、いくつか疑問点。

  • CAは、サーバとクライアントのペアをどうやって識別するのでしょうか?
    Script URLと言うのがこのための識別子のように思うのですが、これは実際にはセッションIDなどを含む、クライアントを識別できるような厳格な識別子になるのかな?

  • Script URLは盗聴可能ではないでしょうか?
    Return HTMLでクライアントはサーバからScript URLを受信し、これを使用してCAへcommon keyを取得しに行くように見えます。
    これって盗聴可能ではないでしょうか?
    Script URLはある意味暗号化通信の秘密鍵であるcommon keyに準ずる秘密情報だと思うのですが、第三者がこれを取得してCAに問い合わせれば、秘密鍵ゲットできそうな。
    盗聴されても平気な仕組みになっていれば話は変わってきますけれど。

  • 暗号化方式は固定でしょうか?
    SSLではSSLセッション確立時に、サーバとクライアント間で手持ちの使用可能な暗号化方式を提示し、相談の上どれを使うか決定しています。このプロセスが存在しませんが、AES固定でしょうか?もしそうだとUAが限定されたり、将来性に難がありそうです。

まだ出てくるかもしれませんが、今気になったのはこの辺です。

======================================
コメントを受けて追記。

一度アクセスされたら以後はステータスコード304を返しています。

真っ当なクライアントが常に一番最初に来ることは保障できないのでは?
例えば無線LANルータやプロキシが盗聴者だった場合などは、Man In The Middle攻撃が成功しませんか?
また、ネットワーク遅延なり瞬断なりでUAが正常にCAからcommon keyを取得できなかった場合にリトライできませんが、最初のフローからやり直しなんでしょうか。

あと、AES固定で行くとして、このSHTTPが普及期に入った5年後あたりには脆弱な暗号化方式になっている可能性は結構ありそうな気がしています。

根本的な話ですが、Open SHTTP CAは従来のCAの証明書発行能力に加えてサーバやクライアントからのリクエストを捌く能力がさらに必要になるようなんですが、現状のSSLより安価になるんでしょうか。

http://qiita.com/kawaz/items/f90810b9ea823b6556a8

ここにあるようにCAであること=無条件に信頼されることであり、信用を維持するのにコストがかかるから証明書の値段に跳ね返ってきているわけで。
サーバ証明書の代わりにScript URLをCAがサーバに対して発行する訳で、よくよく考えてみると少々形の変わったSSLになってるだけのようにも思えてきました。
CAはScript URLを通じて、サーバの実在証明(クライアントがまさにアクセスしようとしている本物である証明)をしているんですよね?

よく考えてあるなーとは思うのですが、いくつか疑問点。

* CAは、サーバとクライアントのペアをどうやって識別するのでしょうか?
Script URLと言うのがこのための識別子のように思うのですが、これは実際にはセッションIDなどを含む、クライアントを識別できるような厳格な識別子になるのかな?

* Script URLは盗聴可能ではないでしょうか?
Return HTMLでクライアントはサーバからScript URLを受信し、これを使用してCAへcommon keyを取得しに行くように見えます。
これって盗聴可能ではないでしょうか?
Script URLはある意味暗号化通信の秘密鍵であるcommon keyに準ずる秘密情報だと思うのですが、第三者がこれを取得してCAに問い合わせれば、秘密鍵ゲットできそうな。
盗聴されても平気な仕組みになっていれば話は変わってきますけれど。

* 暗号化方式は固定でしょうか?
SSLではSSLセッション確立時に、サーバとクライアント間で手持ちの使用可能な暗号化方式を提示し、相談の上どれを使うか決定しています。このプロセスが存在しませんが、AES固定でしょうか?もしそうだとUAが限定されたり、将来性に難がありそうです。

まだ出てくるかもしれませんが、今気になったのはこの辺です。

======================================
コメントを受けて追記。
>一度アクセスされたら以後はステータスコード304を返しています。

真っ当なクライアントが常に一番最初に来ることは保障できないのでは?
例えば無線LANルータやプロキシが盗聴者だった場合などは、Man In The Middle攻撃が成功しませんか?
また、ネットワーク遅延なり瞬断なりでUAが正常にCAからcommon keyを取得できなかった場合にリトライできませんが、最初のフローからやり直しなんでしょうか。

あと、AES固定で行くとして、このSHTTPが普及期に入った5年後あたりには脆弱な暗号化方式になっている可能性は結構ありそうな気がしています。


根本的な話ですが、Open SHTTP CAは従来のCAの証明書発行能力に加えてサーバやクライアントからのリクエストを捌く能力がさらに必要になるようなんですが、現状のSSLより安価になるんでしょうか。

http://qiita.com/kawaz/items/f90810b9ea823b6556a8

ここにあるようにCAであること=無条件に信頼されることであり、信用を維持するのにコストがかかるから証明書の値段に跳ね返ってきているわけで。
サーバ証明書の代わりにScript URLをCAがサーバに対して発行する訳で、よくよく考えてみると少々形の変わったSSLになってるだけのようにも思えてきました。
CAはScript URLを通じて、サーバの実在証明(クライアントがまさにアクセスしようとしている本物である証明)をしているんですよね?

200
 まだ出てくるかもしれませんが、今気になったのはこの辺です。
 
 ======================================
-ついき。
+コメントを受けて追記。
 >一度アクセスされたら以後はステータスコード304を返しています。
 
 真っ当なクライアントが常に一番最初に来ることは保障できないのでは?
 例えば無線LANルータやプロキシが盗聴者だった場合などは、Man In The Middle攻撃が成功しませんか?
-また、ネットワーク遅延なり瞬断なりでUAが正常にCAからcommon keyを取得できなかった場合にリトライできませんが、
-最初のフローからやり直しなんでしょうか。
+また、ネットワーク遅延なり瞬断なりでUAが正常にCAからcommon keyを取得できなかった場合にリトライできませんが、最初のフローからやり直しなんでしょうか。
 
-あと、AES固定で行くとして、このSHTTPが普及期に入った5年後あたりには脆弱な暗号化方式になっている
-可能性は結構ありそうな気がしています。
+あと、AES固定で行くとして、このSHTTPが普及期に入った5年後あたりには脆弱な暗号化方式になっている可能性は結構ありそうな気がしています。
 
 
-根本的な話ですが、Open SHTTP CAは従来のCAの証明書発行能力に加えてサーバやクライアントからのリクエストを
-捌く能力がさらに必要になるようなんですが、現状のSSLより安価になるんでしょうか。
+根本的な話ですが、Open SHTTP CAは従来のCAの証明書発行能力に加えてサーバやクライアントからのリクエストを捌く能力がさらに必要になるようなんですが、現状のSSLより安価になるんでしょうか。
 
 http://qiita.com/kawaz/items/f90810b9ea823b6556a8
 
-ここにあるようにCAであること=無条件に信頼されることであり、信用を維持するのにコストがかかるから証明書の
-値段に跳ね返ってきているわけで。
+ここにあるようにCAであること=無条件に信頼されることであり、信用を維持するのにコストがかかるから証明書の値段に跳ね返ってきているわけで。

よく考えてあるなーとは思うのですが、いくつか疑問点。

  • CAは、サーバとクライアントのペアをどうやって識別するのでしょうか?
    Script URLと言うのがこのための識別子のように思うのですが、これは実際にはセッションIDなどを含む、クライアントを識別できるような厳格な識別子になるのかな?

  • Script URLは盗聴可能ではないでしょうか?
    Return HTMLでクライアントはサーバからScript URLを受信し、これを使用してCAへcommon keyを取得しに行くように見えます。
    これって盗聴可能ではないでしょうか?
    Script URLはある意味暗号化通信の秘密鍵であるcommon keyに準ずる秘密情報だと思うのですが、第三者がこれを取得してCAに問い合わせれば、秘密鍵ゲットできそうな。
    盗聴されても平気な仕組みになっていれば話は変わってきますけれど。

  • 暗号化方式は固定でしょうか?
    SSLではSSLセッション確立時に、サーバとクライアント間で手持ちの使用可能な暗号化方式を提示し、相談の上どれを使うか決定しています。このプロセスが存在しませんが、AES固定でしょうか?もしそうだとUAが限定されたり、将来性に難がありそうです。

まだ出てくるかもしれませんが、今気になったのはこの辺です。

======================================
コメントを受けて追記。

一度アクセスされたら以後はステータスコード304を返しています。

真っ当なクライアントが常に一番最初に来ることは保障できないのでは?
例えば無線LANルータやプロキシが盗聴者だった場合などは、Man In The Middle攻撃が成功しませんか?
また、ネットワーク遅延なり瞬断なりでUAが正常にCAからcommon keyを取得できなかった場合にリトライできませんが、最初のフローからやり直しなんでしょうか。

あと、AES固定で行くとして、このSHTTPが普及期に入った5年後あたりには脆弱な暗号化方式になっている可能性は結構ありそうな気がしています。

根本的な話ですが、Open SHTTP CAは従来のCAの証明書発行能力に加えてサーバやクライアントからのリクエストを捌く能力がさらに必要になるようなんですが、現状のSSLより安価になるんでしょうか。

http://qiita.com/kawaz/items/f90810b9ea823b6556a8

ここにあるようにCAであること=無条件に信頼されることであり、信用を維持するのにコストがかかるから証明書の値段に跳ね返ってきているわけで。

よく考えてあるなーとは思うのですが、いくつか疑問点。

* CAは、サーバとクライアントのペアをどうやって識別するのでしょうか?
Script URLと言うのがこのための識別子のように思うのですが、これは実際にはセッションIDなどを含む、クライアントを識別できるような厳格な識別子になるのかな?

* Script URLは盗聴可能ではないでしょうか?
Return HTMLでクライアントはサーバからScript URLを受信し、これを使用してCAへcommon keyを取得しに行くように見えます。
これって盗聴可能ではないでしょうか?
Script URLはある意味暗号化通信の秘密鍵であるcommon keyに準ずる秘密情報だと思うのですが、第三者がこれを取得してCAに問い合わせれば、秘密鍵ゲットできそうな。
盗聴されても平気な仕組みになっていれば話は変わってきますけれど。

* 暗号化方式は固定でしょうか?
SSLではSSLセッション確立時に、サーバとクライアント間で手持ちの使用可能な暗号化方式を提示し、相談の上どれを使うか決定しています。このプロセスが存在しませんが、AES固定でしょうか?もしそうだとUAが限定されたり、将来性に難がありそうです。

まだ出てくるかもしれませんが、今気になったのはこの辺です。

======================================
コメントを受けて追記。
>一度アクセスされたら以後はステータスコード304を返しています。

真っ当なクライアントが常に一番最初に来ることは保障できないのでは?
例えば無線LANルータやプロキシが盗聴者だった場合などは、Man In The Middle攻撃が成功しませんか?
また、ネットワーク遅延なり瞬断なりでUAが正常にCAからcommon keyを取得できなかった場合にリトライできませんが、最初のフローからやり直しなんでしょうか。

あと、AES固定で行くとして、このSHTTPが普及期に入った5年後あたりには脆弱な暗号化方式になっている可能性は結構ありそうな気がしています。


根本的な話ですが、Open SHTTP CAは従来のCAの証明書発行能力に加えてサーバやクライアントからのリクエストを捌く能力がさらに必要になるようなんですが、現状のSSLより安価になるんでしょうか。

http://qiita.com/kawaz/items/f90810b9ea823b6556a8

ここにあるようにCAであること=無条件に信頼されることであり、信用を維持するのにコストがかかるから証明書の値段に跳ね返ってきているわけで。

200
 SSLではSSLセッション確立時に、サーバとクライアント間で手持ちの使用可能な暗号化方式を提示し、相談の上どれを使うか決定しています。このプロセスが存在しませんが、AES固定でしょうか?もしそうだとUAが限定されたり、将来性に難がありそうです。
 
 まだ出てくるかもしれませんが、今気になったのはこの辺です。
+
+======================================
+ついき。
+>一度アクセスされたら以後はステータスコード304を返しています。
+
+真っ当なクライアントが常に一番最初に来ることは保障できないのでは?
+例えば無線LANルータやプロキシが盗聴者だった場合などは、Man In The Middle攻撃が成功しませんか?
+また、ネットワーク遅延なり瞬断なりでUAが正常にCAからcommon keyを取得できなかった場合にリトライできませんが、
+最初のフローからやり直しなんでしょうか。
+
+あと、AES固定で行くとして、このSHTTPが普及期に入った5年後あたりには脆弱な暗号化方式になっている
+可能性は結構ありそうな気がしています。
+
+
+根本的な話ですが、Open SHTTP CAは従来のCAの証明書発行能力に加えてサーバやクライアントからのリクエストを
+捌く能力がさらに必要になるようなんですが、現状のSSLより安価になるんでしょうか。
+
+http://qiita.com/kawaz/items/f90810b9ea823b6556a8
+
+ここにあるようにCAであること=無条件に信頼されることであり、信用を維持するのにコストがかかるから証明書の
+値段に跳ね返ってきているわけで。

よく考えてあるなーとは思うのですが、いくつか疑問点。

  • CAは、サーバとクライアントのペアをどうやって識別するのでしょうか?
    Script URLと言うのがこのための識別子のように思うのですが、これは実際にはセッションIDなどを含む、クライアントを識別できるような厳格な識別子になるのかな?

  • Script URLは盗聴可能ではないでしょうか?
    Return HTMLでクライアントはサーバからScript URLを受信し、これを使用してCAへcommon keyを取得しに行くように見えます。
    これって盗聴可能ではないでしょうか?
    Script URLはある意味暗号化通信の秘密鍵であるcommon keyに準ずる秘密情報だと思うのですが、第三者がこれを取得してCAに問い合わせれば、秘密鍵ゲットできそうな。
    盗聴されても平気な仕組みになっていれば話は変わってきますけれど。

  • 暗号化方式は固定でしょうか?
    SSLではSSLセッション確立時に、サーバとクライアント間で手持ちの使用可能な暗号化方式を提示し、相談の上どれを使うか決定しています。このプロセスが存在しませんが、AES固定でしょうか?もしそうだとUAが限定されたり、将来性に難がありそうです。

まだ出てくるかもしれませんが、今気になったのはこの辺です。

======================================
ついき。

一度アクセスされたら以後はステータスコード304を返しています。

真っ当なクライアントが常に一番最初に来ることは保障できないのでは?
例えば無線LANルータやプロキシが盗聴者だった場合などは、Man In The Middle攻撃が成功しませんか?
また、ネットワーク遅延なり瞬断なりでUAが正常にCAからcommon keyを取得できなかった場合にリトライできませんが、
最初のフローからやり直しなんでしょうか。

あと、AES固定で行くとして、このSHTTPが普及期に入った5年後あたりには脆弱な暗号化方式になっている
可能性は結構ありそうな気がしています。

根本的な話ですが、Open SHTTP CAは従来のCAの証明書発行能力に加えてサーバやクライアントからのリクエストを
捌く能力がさらに必要になるようなんですが、現状のSSLより安価になるんでしょうか。

http://qiita.com/kawaz/items/f90810b9ea823b6556a8

ここにあるようにCAであること=無条件に信頼されることであり、信用を維持するのにコストがかかるから証明書の
値段に跳ね返ってきているわけで。

よく考えてあるなーとは思うのですが、いくつか疑問点。

* CAは、サーバとクライアントのペアをどうやって識別するのでしょうか?
Script URLと言うのがこのための識別子のように思うのですが、これは実際にはセッションIDなどを含む、クライアントを識別できるような厳格な識別子になるのかな?

* Script URLは盗聴可能ではないでしょうか?
Return HTMLでクライアントはサーバからScript URLを受信し、これを使用してCAへcommon keyを取得しに行くように見えます。
これって盗聴可能ではないでしょうか?
Script URLはある意味暗号化通信の秘密鍵であるcommon keyに準ずる秘密情報だと思うのですが、第三者がこれを取得してCAに問い合わせれば、秘密鍵ゲットできそうな。
盗聴されても平気な仕組みになっていれば話は変わってきますけれど。

* 暗号化方式は固定でしょうか?
SSLではSSLセッション確立時に、サーバとクライアント間で手持ちの使用可能な暗号化方式を提示し、相談の上どれを使うか決定しています。このプロセスが存在しませんが、AES固定でしょうか?もしそうだとUAが限定されたり、将来性に難がありそうです。

まだ出てくるかもしれませんが、今気になったのはこの辺です。

======================================
ついき。
>一度アクセスされたら以後はステータスコード304を返しています。

真っ当なクライアントが常に一番最初に来ることは保障できないのでは?
例えば無線LANルータやプロキシが盗聴者だった場合などは、Man In The Middle攻撃が成功しませんか?
また、ネットワーク遅延なり瞬断なりでUAが正常にCAからcommon keyを取得できなかった場合にリトライできませんが、
最初のフローからやり直しなんでしょうか。

あと、AES固定で行くとして、このSHTTPが普及期に入った5年後あたりには脆弱な暗号化方式になっている
可能性は結構ありそうな気がしています。


根本的な話ですが、Open SHTTP CAは従来のCAの証明書発行能力に加えてサーバやクライアントからのリクエストを
捌く能力がさらに必要になるようなんですが、現状のSSLより安価になるんでしょうか。

http://qiita.com/kawaz/items/f90810b9ea823b6556a8

ここにあるようにCAであること=無条件に信頼されることであり、信用を維持するのにコストがかかるから証明書の
値段に跳ね返ってきているわけで。

回答を投稿

よく考えてあるなーとは思うのですが、いくつか疑問点。

  • CAは、サーバとクライアントのペアをどうやって識別するのでしょうか?
    Script URLと言うのがこのための識別子のように思うのですが、これは実際にはセッションIDなどを含む、クライアントを識別できるような厳格な識別子になるのかな?

  • Script URLは盗聴可能ではないでしょうか?
    Return HTMLでクライアントはサーバからScript URLを受信し、これを使用してCAへcommon keyを取得しに行くように見えます。
    これって盗聴可能ではないでしょうか?
    Script URLはある意味暗号化通信の秘密鍵であるcommon keyに準ずる秘密情報だと思うのですが、第三者がこれを取得してCAに問い合わせれば、秘密鍵ゲットできそうな。
    盗聴されても平気な仕組みになっていれば話は変わってきますけれど。

  • 暗号化方式は固定でしょうか?
    SSLではSSLセッション確立時に、サーバとクライアント間で手持ちの使用可能な暗号化方式を提示し、相談の上どれを使うか決定しています。このプロセスが存在しませんが、AES固定でしょうか?もしそうだとUAが限定されたり、将来性に難がありそうです。

まだ出てくるかもしれませんが、今気になったのはこの辺です。

よく考えてあるなーとは思うのですが、いくつか疑問点。

* CAは、サーバとクライアントのペアをどうやって識別するのでしょうか?
Script URLと言うのがこのための識別子のように思うのですが、これは実際にはセッションIDなどを含む、クライアントを識別できるような厳格な識別子になるのかな?

* Script URLは盗聴可能ではないでしょうか?
Return HTMLでクライアントはサーバからScript URLを受信し、これを使用してCAへcommon keyを取得しに行くように見えます。
これって盗聴可能ではないでしょうか?
Script URLはある意味暗号化通信の秘密鍵であるcommon keyに準ずる秘密情報だと思うのですが、第三者がこれを取得してCAに問い合わせれば、秘密鍵ゲットできそうな。
盗聴されても平気な仕組みになっていれば話は変わってきますけれど。

* 暗号化方式は固定でしょうか?
SSLではSSLセッション確立時に、サーバとクライアント間で手持ちの使用可能な暗号化方式を提示し、相談の上どれを使うか決定しています。このプロセスが存在しませんが、AES固定でしょうか?もしそうだとUAが限定されたり、将来性に難がありそうです。

まだ出てくるかもしれませんが、今気になったのはこの辺です。