作者luckyman186 (luckyman186)
看板NetSecurity
標題Re: [新聞] 監看員工MSN 104人力銀行挨告
時間Mon Jan 18 14:48:54 2010
※ [本文轉錄自 Gossiping 看板]
作者: luckyman186 (luckyman186) 看板: Gossiping
標題: Re: [新聞] 監看員工MSN 104人力銀行挨告
時間: Mon Jan 18 10:56:32 2010
※ 引述《HAIWEI (維)》之銘言:
: 順便告訴各位
: 有個設備叫做blueCxxt以下簡稱BC (避免打廣告嫌疑已馬賽克)
: 他的作法是這樣
: PC<------------>BC<---------->遠端server
: 加密 加密
: 在你pc端上的加密 BC會跟你做一次協定
: 你看起來有加密了 事實上在傳輸中也有加密
: 事實上在BC已經解開了
: 然後BC到遠端server的傳輸也是加密
: 重點在你的資料在BC上已經全部看光了
: 所以你說
: 加密有用嗎?
: 我的答案是科科
: 至於這台設備只比剛才的軟體貴一點點而已
: 大概100多萬就有了
: 大公司你說買不買的起呢 科科
SSH2 能否躲開BC的監控吧? 看"危機"百科的解釋好像是可以
有明白原理的人可以解釋一下嗎?
================================================================
在客戶端來看,SSH提供兩種級別的安全驗證。
* 第一種級別(基於密碼的安全驗證),知道帳號和密碼,就可以登
錄到遠程主機,並且所有傳輸的數據都會被加密。但是,可能會有別的伺
服器在冒充真正的伺服器,無法避免被「中間人」攻擊。
* 第二種級別(基於密匙的安全驗證),需要依靠密匙,也就是你必
須為自己創建一對密匙,並把公有密匙放在需要訪問的伺服器上。客戶端
軟體會向伺服器發出請求,請求用你的密匙進行安全驗證。伺服器收到請
求之後,先在你在該伺服器的用戶根目錄下尋找你的公有密匙,然後把它
和你發送過來的公有密匙進行比較。如果兩個密匙一致,伺服器就用公有
密匙加密「質詢」(challenge)並把它發送給客戶端軟體。從而避免被
「中間人」攻擊。
在伺服器端,SSH也提供安全驗證。在第一種方案中,主機將自己的公用
密鑰分發給相關的客戶端,客戶端在訪問主機時則使用該主機的公開密
鑰來加密數據,主機則使用自己的私有密鑰來解密數據,從而實現主機
密鑰認證,確定客戶端的可靠身份。在第二種方案中,存在一個密鑰認
證中心,所有提供服務的主機都將自己的公開密鑰提交給認證中心,而
任何作為客戶端的主機則只要保存一份認證中心的公開密鑰就可以了。
在這種模式下,客戶端必須訪問認證中心然後才能訪問伺服器主機。
=================================================================
補充
作者
[email protected] (piggy), 看板 security
在 SSH protocol 1 中是用 hostkey 為 session key 加密使用,
但是在 SSH protocol 2 中 hostkey 是用來做為訊息完整性的確
認 (Message Authentication Code) ,而在 MAC 的演算法選擇裡
,是在版本訊息之後,透過類似版本訊息的作法來通知 client,
在 ssharp 實作的假造攻擊中,會對 client 送出 RSA key ,而
這個 RSA key 在真的 server 上是沒有支援的,此時使用者就會
看到新建立的 SSH 連線,而不會看到 Man in The Middle attack
的警告訊息。和真實 server 的溝通可能是 DSA 或 RSA 兩種演算
法,但我們假造的 SSH server 只會送出 RSA 演算法的 key。依
照 RFC 的規定,SSH2 server 在收到 client 所列舉的多種演算
法時,應該是使用第一個演算法,但是 ssharp 的假造 server
會選擇第二種演算法,也就會造成 client 出現 yes/no 的提示,
而非 Man in The Middle attack 警告訊息。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 124.11.225.195
1F:→ Insania:拜請哈維大解惑(跪) 01/18 10:58
2F:推 zx97009:看不懂給個推 01/18 10:58
3F:→ XVN:SSH不是單單雙嗎 01/18 10:59
4F:推 johnlinvc:和我的想法一樣 mitm對金鑰認證法無效 01/18 11:01
5F:推 tetani:變成事先把金鑰給server端 沒有每一連線時的交換過程 01/18 11:03
6F:→ tetani:中間人攻擊法攔截不到金鑰來解密 就沒辦法偷看內容了 01/18 11:04
※ 編輯: luckyman186 來自: 124.11.225.195 (01/18 11:08)
7F:→ laoh:ssh 第一次連線時會把server key 丟過來, 這時被換掉就會被看 01/18 11:10
8F:→ laoh:也不能說是 key 啦, 算 server 的特徵值 01/18 11:12
9F:→ laoh:這個值被改過就會有 warning.. 01/18 11:12
10F:→ reflynet:所以走兩層就不用擔心man in the middle啊... ssh tunnel 01/18 11:13
11F:→ luckyman186:laoh大 指的是 ssh2嗎 01/18 11:13
12F:→ reflynet:+socks proxy.... 這樣在ssh那邊會報錯 01/18 11:13
13F:→ drwei:沒八卦 去電腦版啦 01/18 11:34
14F:→ taroa:只要一開始在自家網路設定好public-key應該是安全的 01/18 13:17
15F:→ taroa:不過會想到這麼多的公司員工本身就很可疑 01/18 13:20
16F:推 ian1009:回到傳統的密碼本吧~第幾行第幾個字MSN內容座標化... 01/18 14:23
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 124.11.228.222
17F:推 celicx:BC只能看WLM8.5之前的版本,8.5之後都不支援了... 01/21 16:24
18F:→ celicx:至於SSL的部份,的確就像文內所說的BC可以分2段吃SSL驗證 01/21 16:25
19F:→ celicx:Client to BC(第一段),BC to Web Service(第二段) 01/21 16:26
20F:→ celicx:至於ssh2,如果是透過BC的socks是可以被解開的(實驗過= =) 01/21 16:27
21F:推 OpenSkyWin:請問如果有人用bc,那麼我browser看SSL的網應該會警告? 01/24 18:45
22F:→ OpenSkyWin:ssh2的話,我如果先前已經有連過這個網站,存有之前的key 01/24 18:46
23F:→ OpenSkyWin:在known_host檔裡面,再被別人用BC監視時,也會跳出警告? 01/24 18:47