About Me - 關於我的一切

經歷

- 新創公司（供應鏈相關）一年半：Frontend Developer

- 新創公司（DCIM）一年：Frontend Developer

- 四大會計事務所：Senior Cybersecurity Consultant


創作相關背景

鐵人賽

- 第15屆 IT 鐵人賽 (優選)：從自建漏洞中學習 - 一起填坑吧！

- 第16屆 IT 鐵人賽：前端小廢物誤入 Hackthebox Module

出版書籍

- 究極 Web 資安心智圖學習法！嚴選12大主題 × 7張心智圖 × 7個實戰，核心技能無痛升級（iThome鐵人賽系列書）: 天瓏書局網站 


社群背景

- DevSecOps Taiwan：社群 Leader

- 台科資安社：社員


正在準備的證照

- OSCP

- 托福

留言

張貼留言

這個網誌中的熱門文章

資安基礎惡補 - 網路篇 - DNS

圖片
DNS 使命 將域名解析為 IP 地址。 解析流程 客戶端查詢 (DNS Resolver) 當輸入某個 Domain name 時，瀏覽器會向系統的本地 DNS Resolver 提出請求。 本地 DNS 伺服器 (Recursive Resolver) 本地 DNS 伺服器接收請求，並會根據是否有緩存決定要從哪邊拿資料。總共會有以下情況： 有緩存：如果此前查詢過該域名，本地伺服器會直接返回緩存結果。 無緩存：迭代查找。 Root Server 在本地 DNS 伺服器請求 Root Server（如 . ）後，Root Server 會告訴本地伺服器要查詢哪個頂級域名（TLD）伺服器。 TLD Server 在本地 DNS 伺服器查詢 TLD Server（如 .com ）後，TLD Server 會返回權威伺服器 - Authoritative Server（如 ns1.example.com ）。 權威伺服器 Authoritative Server 權威伺服器返回域名對應的 IP 地址。 Client 端接收 IP 本地 DNS 伺服器將結果返回給 Client 端，瀏覽器使用該 IP 地址與伺服器建立連接。 DNS 查找工具 - nslookup 我們可以使用 nslookup 來查詢 DNS 相關的訊息、域名與 IP 地址之間的對應關係。 從上方的資訊我們可以得知從非權威的 Server 中回傳了 domain name 和對應的 ipv4 address。 當然，如果想要使用公用的 google DNS 伺服器查詢 google.com 的位址，可以這麼做： 就會使用 Google 的公共 DNS 伺服器（ 8.8.8.8 ）查詢 google.com 。 不想用 DNS 可以怎麼做？ 我們可以試著反向思考，假設我們不想使用 DNS Server，我們可以怎麼做呢？ 1. 使用 Hosts 文件 以 MacOS / Linux 為例子，我們可以在 /etc/hosts 修改 IP 和域名的 mapping： 2. 自己輸入 IP 3. 使用靜態 IP 配置與 Nginx / Load Balancer 常見的 DNS Record 1. A   IPv4 地址記錄。  2. AAAA  IPv6 地址記錄。  3....
閱讀完整內容

SSL/TLS 協定知多少 - 基礎篇

圖片
前言 SSL / TLS ? 最近筆者剛轉職，正要進行第一個專案 👾 在某次 Sync 的會議中突然被問到： 舊版本的 SSL/TLS 為什麼危險，應該知道吧？  腦中突然浮現：「啊！之前在看 Microsoft 官方文檔確實有看到這塊，它建議升版 o.o」 好了，問題來了！ 那更深層次的問題，以及如何清楚解釋，我知道嗎？ 於是就有了這篇的誕生 ☺ 讓我們看下去吧！ 為什麼過去的 SSL/TLS 舊版協定比較危險？ 先聊聊什麼是 SSL/TLS SSL（Secure Sockets Layer）/  TLS（Transport Layer Security） 是一種用來 加密網路連線 的安全協定，用來確保你和網站之間傳輸的資料 不會被偷看、不會被竄改。 TLS 是 SSL 的後續版本，目前已發展到 TLS 1.3，具備更高的安全性與效能；舊版本如 SSL 3.0、TLS 1.0 和 1.1 已被淘汰，現代網站多採用 TLS 1.2 或 TLS 1.3 作為主流標準。 相關重點：SSL/TLS 握手（以 TLS 1.2 為例） 當 TLS 或 SSL 連線開始時，雙方會進行一個關鍵步驟叫做：「握手（Handshake）」。 這就像談戀愛前的「 確認彼此身分與溝通規則 」，要談情說愛之前，得先確定你是誰、我們怎麼講話、要不要加密、用哪種暗號（Cipher Suite）😇 握手的過程像是以下這樣： 關鍵澄清： 上方的圖片代表的是邏輯步驟，實際上這五個步驟不等於五個「RTT（Round Trip Time）」～ TLS 1.2 的實際 RTT 解釋如下：   在 TLS 1.2 中，完成一次完整握手大約需要「兩次往返（2-RTT）」的傳輸時間：  1. 第一個 RTT：  Client 發送 Client Hello（我支援這些 Cipher Suites）  Server 回應 Server Hello + 憑證 + Key Exchange + Hello Done  2. 第二個 RTT：  Client 發送 Client Key Exchange + Change Cipher Spec + Finished  Server 回應 Change Cipher Spec ...
閱讀完整內容