通訊是雙向的 , Server端用Private key解密 , 那client端接收Server端的packet 時
用那個key來解密 ?? public key ??

session key 啊.
step 4 之後, 兩邊都有 session key 了, 就全用這個在加解密了. (session key 是 client 產生, 然後用 public key 加密後送給 server, 所以.... 理論上只有 client 本身與有 private key 的 server 才能知道 session key 是什麼)

client 收到的未加密資料只有 public key, 而這本來就是公開的, 只有 public key 也只能用來加密, 不能用來解密.

嗯....

在我的認知裡,如果client是必須透過Proxy來access SSL , 那session key 也會被欄劫
在這種環境裡,恐怕ssl傳輸的內容還是有機會被看光光 , 除非在沒有proxy的環境裡 , SSL
才算是相對的安全吧?
----

終於瞭解了... 重點就在於public key 只能加密,不能用來解密 ....

謝謝您的提點!!

所以只要不連proxy server
SSL加密就不會被破解嗎?

正常來說, 用 proxy server 也不會被破解.
proxy server 也看不到未加密的 session key. 只能照著收送資料, 沒辦法知道資料的內容.

上頭的前提是你看到的 cert 是真的要連的那一台機器的. 這就是為什麼要花錢去買 cert....
因為自己產生的, 對於一般的 browser, 會認定那個認證有問題, 而一般都叫使用者忽略它, 結果就是.... 如果真的 proxy 假造一個來用的話, 對於 browser 那邊的使用者可能就不會認出來那是有問題的.

以SSL的運作原理來看, 如果proxy只是單純forward client request , 那應該是不易破解!!

但,如果client access ssl時,是與proxy建立ssl connection , 而proxy再與server端建立ssl connection
proxy 所擔任的中間人角色, 還是可以將SSL內容給加解密出來 !!

我是聽說Squid 新版本就有支援SSL的加解密 , 所以....

中間人攻擊

Heartbleed bug

http://zh.wikipedia.org/wiki/%E5%BF...%BC%8F%E6%B4%9E

呃.......

我相信這指的應該不是我之前說的ssl proxy 的方式 ,維基已經有點到是利用openssl 的漏洞進行的!!

只是,我最近也有點頭痛 , 我自己用的Firefox(最新版) 居然不肯與自己的網站建立SSL connection
只有IE(舊版本) 沒問題 , Google後才發現說 Firefox建議網站管理員更新openssl 並使用TLSv3 連線來解決

這......搞了半天,我還以為是自己的SSL有問題,原來是Firefox不肯建立SSL連線啊.... :jolin: :jolin: :jolin: