日本賞楓：紅葉紅到哪了?
我想在出發前最想知道的就是現在楓紅的狀況如何了？日本在這方面的資訊還蠻容易查的 http://map.mapple.net 點選紅葉地圖 左方就可以顯示紅葉的狀況，5-7天會更新一次： 紅葉地圖 直接連結 另一個連結： 季節特集： http://www.rurubu.com/season/
發表文章
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： 正確的發行者應像這樣： 信有朝一日，假的憑證資料應該也會長