搜尋此網誌

2008/11/14

日本賞楓:紅葉紅到哪了?

我想在出發前最想知道的就是現在楓紅的狀況如何了?日本在這方面的資訊還蠻容易查的



http://map.mapple.net點選紅葉地圖
左方就可以顯示紅葉的狀況,5-7天會更新一次:

紅葉地圖直接連結

另一個連結:
季節特集:http://www.rurubu.com/season/

京都2008/11/16-20天氣預測

16號可能會下雨orz...然後溫度一路下滑到20號的13/4度
資料來源:Yahoo Japan


無內文

2008/11/11

HTTPS的傳輸綁架事件

有標示著金鎖的網頁也不一定是安全的,尤其是在一個注重安全的企業內使用的話,你有空更應該看看金鎖的內容有沒有問題。


關於HTTPS/TLS加密傳輸:
一般來說,透過HTTS/TLS連線是很安全的,也就是說連線的過程有經過加密,以確保傳輸的資料並不會被第三者竊取,HTTPS的簡單連線程序如下:

1.用戶端欲連到HTTPS網站A
2.用戶端經由第三方公證單位,得到網站A的公鑰
3.用戶端把認證資料經網站A的公鑰加密,送給網站A(例如345+1=?)
4.網站A收到用戶端的資料後,用私鑰解密,回答用戶端的問題後,再將結果用私鑰加密(回答345+1=346)
5.用戶端收到加密後的資料後,用網站A的公鑰解密後,看答案對不對,如果對的話,雙方協調,用金鑰加密一組只在這次連線有用的Session Key,以後資料都用Session Key來加解密。由於Session Key是對稱式加解密,故加解密速度快很多。

RFC 2246中有關TLS傳輸協定的簡圖


HTTPS的傳輸資料綁架

如果在第三步驟時,第三者把用戶端要連線到網站A時,就假造自己是網站A,然後有如中介者一般,回應和處理用戶和網站A的資料傳輸,如此第三者就能完全知道用戶端和網站A之間的任何傳輸內容;首先它自己產生一對金鑰,回傳給用戶端,然後再把自己扮成用戶端,和網站A溝通,如此一來就沒有任何資料可逃過第三者的查緝。
第三者如果是代理伺服器的話,那麼就代表任何資料通過此代理伺服器後,沒有任何秘密可言。例如網路銀行的交易,都不再是安全的。


綁架事件實例
IE對這方面的處理並不是很完善,IE 7沒試過,不過IE 6在畫面的右下角,還是出現一個表示安全的金鎖,點擊金鎖,才會發現憑證大有問題,例如連到https://www.chinatrust.com.tw,由下方可看出發行者是The same as above,真是敷衍的發行者名稱!
這不代表上述網站有問題,而是憑證已經不是原網站的憑證了。原網站對外發行的憑證還是對的,只是被中間的代理伺服器動過手腳。

大有問題的憑證,發行者單位怪怪的:



讓我們來看看正確的憑證應長得像這樣,下方IE為英文介面,不過發行者可看出是VeriSign:



皆著,看一下假造的憑證詳細資料,真是隨便到不行,全都是The same as above:



正確的發行者應像這樣:



信有朝一日,假的憑證資料應該也會長得像真的一樣,讓你在IE中認不出來。最後的防線,請使用Firefox,Firefox在憑證檢查方面嚴謹了不少,一旦發現憑證有問題,是不會先連上網站的,因為憑證有問題,代表如果不是傳輸過程中有人動了手腳,不然就是這個網站,不是本來應該去的那一個,而是一個釣魚網站,來看看Firefox怎麼說:


結論是,還是乖乖用Firefox吧! 至少以這例子來說,IE 6並不能檢查出問題。