採購110年度全校防毒軟體更新授權，提供更完善的資訊安全防護，已於7月30日進行驗收程序。

微軟上周宣布，TLS 1.3將從Build 20170開始，在Windows 10 Insider預覽版預設開啟，而這表示未來將推向所有Windows 10版本。 TLS 1.3（Transport Layer Security，傳輸層安全性協定）於2018年公布，是最新版網際網路傳輸加密協定，移除了不安全的加密演算法，也比前版提高加密安全性，旨在儘可能加快加密用戶端及伺服器端的交握速度。 主要瀏覽器包括Chrome、Edge、Firefox和Safari已公布2020年起，終止支援TLS1.0及1.1。雖然受到武漢肺炎疫情影響，微軟今年稍早延長支援期到2020年下半，不過最快7月就會切斷支援，呼籲網站開發商升級到1.2版以上。 事實上，微軟強烈建議App及服務開發商及早開始測試TLS 1.3。微軟指出，TLS 1.3使用3種密碼套件，包括：TLS_AES_128_GCM_SHA256、TLS_AES_256_GCM_SHA384、TLS_CHACHA20_POLY1305_SHA256，全部都有PFS（perfect forward secrecy，完整轉寄密碼）、AEAD（authenticated encryption with associated data）特性及現代化演算法，可解決過去因為定義了太多密碼套件，而導致的不相容及安全性不穩定的問題。 此外它也儘可能降低傳送的明碼協定字元，以避免協定僵化（ossification）、提升隱私性，並隱藏傳送的內容長度，減少資訊暴露風險。此外，前幾版的TLS中，用戶端的身分很容易因用戶端驗證曝露，但TLS 1.3已經看不到用戶端驗證。 微軟也計畫從.NET 5.0開始支援TLS 1.3。 至於在瀏覽器方面，配合TLS 1.3的部署，IIS/HTTP.SYS也預設開啟TLS1.3。即將在明年終止大部份支援的IE及舊版Edge，現在仍然可以在進階設定下開啟支援。Chromium Edge下則可透過Edge://flags來啟用。

研究人員Allison Husain發現G Suite後端全域郵件流程規則（global mail routing rule）設定允許變更收信人，這讓她得以指定任意收信者。而G Suite卻也未驗證就接受了這個收件者值。這使得攻擊者得以利用Google後端將任何信件轉寄出去。（圖片來源／Allison Husain）

Google稍早針對Gmail和G Suite郵件系統釋出修補程式，以解決一個通報137天、可被人用來發出冒名郵件的漏洞。 這項漏洞是由研究人員Allison Husain發現後向Google通報。這個漏洞發生在Google後端郵件流程規則上，造成冒名轉發，再配合郵件閘道的使用，使攻擊者得以繞過現代郵件系統嚴格的SPF/ DMARC規則保護，冒充G Suite/Gmail用戶發送冒名郵件給他人。 SPF（Sender Policy Framework）和DMARC（Domain-based Message Authentication, Reporting, and Conformance）的規則可防止普通冒名信件。原理是將一組網域許可的發信者IP清單交給郵件伺服器比對，不在清單上的IP送出的信，包括冒名或釣魚信件就不會被郵件伺服器接收；反之合法來源送來的信就會被接受。但是研究人員發現的冒名信件攻擊，卻是Google環境獨有。 研究人員解釋，G Suite後端全域郵件流程規則（global mail routing rule）設定允許變更收信人，這讓她得以指定任意收信者。而G Suite卻也未驗證就接受了這個收件者值。這使得攻擊者得以利用Google 後端將任何信件，包括冒名信件轉寄出去。而在收信端的郵件伺服器上，來自Google（Gmail、G Suite）後臺的信件，可通過SPF/DMARC規則檢查而被視為合法來源的信。另外，研究人員又發現，只要轉發自Gmail、G Suite的信件包含郵件閘道設定，則終端郵件伺服器就會自動通過SPF/DMRAC檢測，確保郵件連被隔離的可能性都沒有，而是會直接進入收件者信箱。 整合G Suite郵件驗證規則中的收信者驗證錯誤及信件閘道，讓攻擊者得以讓Google後端轉發任何網域的信件，包括冒名郵件。而如果被冒名的人剛好也同時有用Gmail或G Suite就更好了，因為這些人的網域會設定允許Google後臺轉發其網域的信件，而可順利通過SPF及DMARC的檢查。另一好處是，垃圾郵件過濾引擎也往往較不會攔阻或封鎖來自Gmail、G Suite的郵件 研究人員指出，Google獨有的漏洞讓攻擊者得以發送冒名信件，就連有SPF/SMARC規則防護也會被繞過，使企業用戶面臨詐欺信件或商業電子郵件詐騙（Business Email Compromise，BEC）。 Husain於4月初發現該漏洞後即通報Google，但是等到8月1日卻仍不見Google修補的跡象。8月中Google表示，要到9月17日才會釋出修補程式。8月19日時，研究人員以超過137天為由公布漏洞。而在公布後7小時，Google就完成修補。雖然拖了4個月才完成修補，但研究人員仍然讚揚Google態度良好且動作迅速。