質問編集履歴
4
追記
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -45,3 +45,13 @@
|
|
|
45
45
|
|
|
46
46
|
|
|
47
47
|
調べた内容は、申し訳ありませんが、他にありません。
|
|
48
|
+
|
|
49
|
+
|
|
50
|
+
|
|
51
|
+
### 追記 2019/06/13 13:56
|
|
52
|
+
|
|
53
|
+
[maisumakun](https://teratail.com/users/maisumakun)さんよりコメントいただきまして、
|
|
54
|
+
|
|
55
|
+
アクセスするurlと証明書の間でコモンネームを確認することを念頭に置いていませんでした。
|
|
56
|
+
|
|
57
|
+
解決しました。ご迷惑おかけしました。
|
3
誤植を修正2
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -34,9 +34,9 @@
|
|
|
34
34
|
|
|
35
35
|
2. examplebank.comで解決されるサーバーがサーバ証明書を送付する
|
|
36
36
|
|
|
37
|
-
2.evil. ここで中間者が証明書を注入
|
|
37
|
+
2.evil. ここで中間者がevilexamplebank.com証明書を注入
|
|
38
38
|
|
|
39
|
-
3. クライアントが証明書の公開鍵を確認し、共通鍵を作成、送付
|
|
39
|
+
3. クライアントがevilexamplebank.com証明書の公開鍵を確認し、共通鍵を作成、送付
|
|
40
40
|
|
|
41
41
|
4. 中間者が共通鍵を復号
|
|
42
42
|
|
2
誤植を修正
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -32,7 +32,7 @@
|
|
|
32
32
|
|
|
33
33
|
1. クライアントがhttps://examplebank.comにアクセスする
|
|
34
34
|
|
|
35
|
-
2. サーバーがサーバ証明書を送付する
|
|
35
|
+
2. examplebank.comで解決されるサーバーがサーバ証明書を送付する
|
|
36
36
|
|
|
37
37
|
2.evil. ここで中間者が証明書を注入
|
|
38
38
|
|
1
前提を追記しました
test
CHANGED
|
File without changes
|
test
CHANGED
|
@@ -11,3 +11,37 @@
|
|
|
11
11
|
- ユーザー側でドメインを確認してもらうことで防げること。
|
|
12
12
|
|
|
13
13
|
- ユーザー側で証明書を確認してもらうことで防げること。
|
|
14
|
+
|
|
15
|
+
|
|
16
|
+
|
|
17
|
+
### 追記 2019/06/13 13:31
|
|
18
|
+
|
|
19
|
+
[mikkame](https://teratail.com/users/mikkame)さん、[maisumakun](https://teratail.com/users/maisumakun)さんが回答していただいた後の追記となります。前提覆るかもしれませんが、申し訳ございません。
|
|
20
|
+
|
|
21
|
+
|
|
22
|
+
|
|
23
|
+
ここでの証明書を中間者独自のサイトのドメインを使った証明書ということにすると、どうでしょうか。
|
|
24
|
+
|
|
25
|
+
つまり、中間者のサイト自体は悪意あるかどうかは別として、証明書の検証やドメイン所有のチェックにかかる問題はないことを想定します。
|
|
26
|
+
|
|
27
|
+
したがってブラウザ上部に表記されるドメインは厳密には別のドメインになっているものと思われます。
|
|
28
|
+
|
|
29
|
+
|
|
30
|
+
|
|
31
|
+
TLSのハンドシェイク初期について私の想定する懸念は、以下の通りです。
|
|
32
|
+
|
|
33
|
+
1. クライアントがhttps://examplebank.comにアクセスする
|
|
34
|
+
|
|
35
|
+
2. サーバーがサーバ証明書を送付する
|
|
36
|
+
|
|
37
|
+
2.evil. ここで中間者が証明書を注入
|
|
38
|
+
|
|
39
|
+
3. クライアントが証明書の公開鍵を確認し、共通鍵を作成、送付
|
|
40
|
+
|
|
41
|
+
4. 中間者が共通鍵を復号
|
|
42
|
+
|
|
43
|
+
->その後、中間者がサイトの内容を偽装する形でクライアントと通信。
|
|
44
|
+
|
|
45
|
+
|
|
46
|
+
|
|
47
|
+
調べた内容は、申し訳ありませんが、他にありません。
|