คู่มือ HTTPS สำหรับวิศวกรธรรมดา

 (devonperoutky.super.site)
6 คะแนน โดย GN⁺ 2024-05-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • การสื่อสารบนอินเทอร์เน็ตมีโครงสร้างที่หลายชั้นช่วยกันจัดการแพ็กเก็ต และด้วย โปรโตคอลแบบแบ่งชั้น นักพัฒนาจึงไม่จำเป็นต้องจัดการรายละเอียดการส่งข้อมูล การเราต์ หรือความปลอดภัยด้วยตนเอง
  • คำขอ HTTP เริ่มจากการสร้างข้อความในเบราว์เซอร์ แล้วต่อด้วยการค้นหา DNS, TCP 3-way handshake, การผ่านเราเตอร์, และการตอบกลับจากเซิร์ฟเวอร์ ตาม ลำดับขั้นตอน
  • HTTP แบบพื้นฐานส่งส่วนหัวและเนื้อหาเป็นข้อความล้วน จึงเสี่ยงต่อการดักฟังและการปลอมเป็นเซิร์ฟเวอร์ และเพื่อแก้ข้อจำกัดนี้จึงมีการเพิ่ม ชั้นความปลอดภัย เข้าไป
  • HTTPS คือ HTTP ที่เพิ่มการเข้ารหัสและการตรวจสอบด้วย TLS โดย TLS handshake คือกระบวนการตกลงข้อมูลอย่างเวอร์ชัน, cipher suite, ใบรับรอง, และข้อมูลการแลกเปลี่ยนกุญแจ เพื่อสร้าง กุญแจเซสชันแบบสมมาตร
  • TLS 1.3 ตัด RSA และ cipher suite หรือพารามิเตอร์ที่อ่อนแอออกไป และลดตัวเลือกให้เหลือน้อยลง ทำให้ handshake เรียบง่าย เร็ว และปลอดภัยกว่าเดิม

โมเดลแบบแบ่งชั้นสำหรับมองการสื่อสารบนอินเทอร์เน็ต

  • อินเทอร์เน็ตคือเครือข่ายของเครือข่ายคอมพิวเตอร์ที่เชื่อมต่อถึงกัน และ “Internet” มีความหมายตามตัวอักษรว่า “ระหว่างเครือข่าย”
  • มันทำงานในรูปแบบ mesh network ที่สื่อสารด้วยการสลับแพ็กเก็ต และเป็นโครงสร้างแบบ best-effort delivery ที่ไม่ได้รับประกันว่าจะแพ็กเก็ตจะถูกส่งถึงหรือจะไปถึงเมื่อไร
  • การลองส่งใหม่ การรับประกันลำดับ การกำจัดข้อมูลซ้ำ และความปลอดภัย ล้วนถูกดูแลอยู่เบื้องหลังโดยชั้น abstraction หลายระดับ จึงทำให้อินเทอร์เน็ตดูเหมือนทำงานได้อย่างลื่นไหล
  • แต่ละชั้นมีหน้าที่เฉพาะ และ protocol ที่ต่างกันก็สามารถนำหน้าที่นั้นไปใช้งานได้
    • ด้วยการแยกส่วนแบบนี้ แม้จะเปลี่ยนโปรโตคอลในชั้นหนึ่ง ก็อาจไม่กระทบโปรโตคอลของชั้นอื่น

บทบาทของแต่ละชั้นในเครือข่าย

  • Application layer จัดการลอจิกเฉพาะของแต่ละแอปพลิเคชัน หน่วยการสื่อสารคือ message และ HTTP เป็นตัวอย่างที่เด่นชัด
  • Security layer ให้ความสามารถด้านการเข้ารหัสและการยืนยันตัวตน หน่วยการสื่อสารคือ record และ TLS เป็นตัวอย่าง
  • Transport layer รับผิดชอบการส่งข้อมูลอย่างเชื่อถือได้ โดยใช้ TCP segment หรือ UDP datagram และระบุปลายทางด้วยหมายเลขพอร์ต
  • Network layer ทำหน้าที่เราต์แพ็กเก็ตข้ามอินเทอร์เน็ต โดยใช้ IP address เป็นตัวระบุ
  • Link layer จัดการการสื่อสารที่ใกล้กับตัวกลางทางกายภาพ ใช้ frame และระบุด้วย MAC address
  • Physical layer ส่งบิตระหว่างอุปกรณ์ในเชิงกายภาพ โดยมีตัวอย่างเช่นใยแก้วนำแสงหรือ Ethernet cable

ลำดับการไหลของคำขอ HTTP

  • 1. ไคลเอนต์สร้างคำขอ

    • กระบวนการเริ่มที่ Application layer และโดยทั่วไปไคลเอนต์ก็คือเว็บเบราว์เซอร์
    • HTTP เป็นโปรโตคอลแบบข้อความ จึงส่งข้อมูลเป็นข้อความล้วน
    • บรรทัดแรกของคำขอ HTTP โดยทั่วไปจะมี HTTP method, resource ที่ร้องขอ, และเวอร์ชันของโปรโตคอล
      • HTTP method: GET, POST เป็นต้น
      • resource ที่ร้องขอ: เช่น /index.html
      • เวอร์ชันของโปรโตคอล
    • ส่วนที่เหลือของข้อความ HTTP จะประกอบด้วย header ในรูปแบบ key: value และเนื้อหาที่อาจมีหรือไม่มีก็ได้
    GET /index.html HTTP/1.1
Host: www.example.com
Accept: text/html
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.212 Safari/537.36

  • 2. การค้นหา DNS

    • DNS แปลงชื่อโดเมนที่มนุษย์อ่านได้อย่าง www.example.com ให้เป็น IP address อย่าง 93.184.216.34
    • ไคลเอนต์จะสอบถาม DNS server เพื่อ resolve ชื่อโดเมนให้เป็น IP address
    • กระบวนการนี้จะผ่าน resolver หลายตัว และสุดท้ายไปถึง authoritative server
    • Stub resolver อยู่บนเครื่องไคลเอนต์ และส่งต่อคำขอไปยัง recursive resolver ที่เหมาะสม
    • Recursive resolver รับคำขอจาก stub resolver แล้วไปสอบถาม authoritative server และมักจะ cache ผลลัพธ์ไว้
    • โดยทั่วไป ISP จะให้บริการ recursive resolver และยังสามารถใช้ public resolver อย่าง Google DNS 8.8.8.8 ได้ด้วย
    • Authoritative server มี DNS record จริงอย่าง A, MX, CNAME และเป็นแหล่งข้อมูลสุดท้ายของข้อมูลชื่อโดเมน

  • 3. TCP handshake

    • เมื่อได้ IP address ของเซิร์ฟเวอร์แล้ว ไคลเอนต์จะเตรียมการส่ง HTTP ที่ Transport layer
    • โปรโตคอลหลักของ transport layer คือ TCP และ UDP
    • TCP เป็นโปรโตคอลแบบ connection-oriented และรับประกันความน่าเชื่อถือ ลำดับ และการตรวจสอบข้อผิดพลาดของการส่งข้อมูลระหว่างแอปพลิเคชัน
    • UDP เป็นโปรโตคอลแบบ connectionless และไม่ได้รับประกันการส่งถึง ลำดับ หรือการตรวจสอบข้อผิดพลาด แต่แลกกับความเร็วและ overhead ที่ต่ำกว่า
    • ณ ปี 2024 TCP ยังเป็นโปรโตคอลหลักสำหรับจัดการการส่งข้อมูลบนอินเทอร์เน็ต ส่วน UDP มักใช้กับแอปพลิเคชันแบบเรียลไทม์ เช่น สตรีมมิงหรือวิดีโอคอล ที่ให้ความสำคัญกับ latency ต่ำและยอมรับการสูญหายของแพ็กเก็ตบางส่วนได้
    • จะเริ่มการเชื่อมต่อ TCP ไปยัง พอร์ต 80 ซึ่งเป็นพอร์ตมาตรฐานของ HTTP และผ่าน 3 ขั้นตอนของ handshake
      • SYN: ไคลเอนต์ส่งแพ็กเก็ต SYN เพื่อขอเริ่มการเชื่อมต่อ
      • SYN-ACK: เซิร์ฟเวอร์ตอบรับคำขอด้วยแพ็กเก็ต SYN-ACK
      • ACK: ไคลเอนต์ส่งแพ็กเก็ต ACK เพื่อให้การเชื่อมต่อแบบเชื่อถือได้ถูกสร้างขึ้น

  • 4. การส่งคำขอ HTTP

    • เมื่อการเชื่อมต่อ TCP พร้อมแล้ว ไคลเอนต์จะส่งคำขอ HTTP จริง
    • เนื่องจาก HTTP เป็นโปรโตคอลแบบข้อความ หากมีทั้ง header และ body ก็จะถูกส่งเป็น ข้อความล้วน ทั้งหมด

แพ็กเก็ตเดินทางไปถึงเซิร์ฟเวอร์ได้อย่างไร

  • เมื่อไคลเอนต์ส่งคำขอแล้ว แพ็กเก็ตข้อมูลจะไม่ได้เดินทางตรงไปยังเซิร์ฟเวอร์ แต่จะค้นหาเส้นทางผ่านอุปกรณ์เครือข่ายและเราเตอร์หลายตัว เพื่อไปยัง gateway ของเครือข่ายเซิร์ฟเวอร์
  • จากนั้น Link layer จะรับผิดชอบการส่งข้อมูลในช่วงเครือข่ายท้องถิ่น

  • ขั้นตอนที่ข้อความข้ามอินเทอร์เน็ต

    • อุปกรณ์ไคลเอนต์จะ encapsulate ข้อมูลคำขอ HTTP เป็น TCP segment แล้วห่ออีกชั้นเป็น IP packet
    • หากเป็นการเชื่อมต่อแบบมีสาย ก็จะถูก encapsulate อีกครั้งเป็น Link layer frame เช่น Ethernet frame
    • frame จะถูกส่งผ่านเครือข่ายท้องถิ่นไปยังเราเตอร์ของไคลเอนต์
    • เราเตอร์ท้องถิ่นจะรับ frame มา ลบ Link layer header ออก แล้วประมวลผล IP packet
    • เราเตอร์จะดู IP address ปลายทางแล้วตัดสินใจ next hop
    • แพ็กเก็ตจะถูกส่งต่อผ่านเราเตอร์กลางหนึ่งตัวหรือมากกว่าไปยังเครือข่ายถัดไป และแต่ละเราเตอร์ก็จะทำซ้ำกระบวนการเลือก next hop แล้วส่งต่อ
    • ในที่สุดแพ็กเก็ตจะไปถึงเราเตอร์ที่อยู่ในเครือข่ายเดียวกับเซิร์ฟเวอร์ปลายทาง
    • เราเตอร์ตัวนี้จะตัดสินใจเราต์ขั้นสุดท้าย แล้วส่งแพ็กเก็ตไปยังอุปกรณ์ท้องถิ่นที่เป็นเซิร์ฟเวอร์
    • เราเตอร์ฝั่งเซิร์ฟเวอร์จะส่งแพ็กเก็ตไปยังเซิร์ฟเวอร์ผ่าน local network segment
    • Link layer จะทำให้แน่ใจว่า frame ถูกส่งไปยัง network interface ของเซิร์ฟเวอร์อย่างถูกต้อง
    • เซิร์ฟเวอร์จะรับ frame แยกเอา IP packet ออก แล้วประมวลผล TCP segment ที่ถูก encapsulate ไว้เพื่อประกอบกลับเป็นคำขอ HTTP เดิม
    • กระบวนการของ Network layer ที่ส่งแพ็กเก็ตข้ามอินเทอร์เน็ตนี้ ยังถูกใช้ในขั้นตอนก่อนหน้าอย่างการ resolve ชื่อโดเมนหรือ TCP handshake ด้วย

การตอบกลับจากเซิร์ฟเวอร์และการเรนเดอร์ของเบราว์เซอร์

  • เซิร์ฟเวอร์จะประมวลผลคำขอ HTTP แล้วส่ง HTTP response กลับไปยังไคลเอนต์
  • response จะประกอบด้วยเวอร์ชัน HTTP ที่ใช้งานอยู่, status code อย่าง 200 หรือ 404, response header, และ body เช่น HTML ของหน้าที่ร้องขอหรือข้อมูล JSON
HTTP/1.1 200 OK
Date: Sat, 26 May 2023 10:00:00 GMT
Server: Apache/2.4.41 (Ubuntu)
Content-Type: text/html
Content-Length: 3456

    Example Page

    Hello, world!
  • ไคลเอนต์จะรับและประมวลผล HTTP response
  • เบราว์เซอร์จะตีความ HTML แล้วเรนเดอร์เนื้อหาบนหน้าจอ
  • หาก response มีทรัพยากรเพิ่มเติมอย่างรูปภาพ CSS หรือ JavaScript เบราว์เซอร์ก็จะส่งคำขอ HTTP เพิ่มเติมตามกระบวนการเดียวกัน

ปัญหาด้านความปลอดภัยของ HTTP และ HTTPS

  • HTTP แบบพื้นฐาน ไม่มีความปลอดภัยเลย
  • ผู้ที่ดักฟังการเชื่อมต่อสามารถเห็นข้อมูลที่รับส่งกันได้ 100%
  • หากมีใครสวมรอยเป็นเซิร์ฟเวอร์ ไคลเอนต์ก็อาจส่งข้อมูลสำคัญไปยังปลายทางที่ผิดได้
  • HTTPS คือรูปแบบที่เพิ่มการเข้ารหัสและการตรวจสอบเข้าไปใน HTTP
  • วิธีทำให้การสื่อสาร HTTP ปลอดภัยมีหลายแบบ แต่การใช้งานที่ใช้กันทั่วไปในปัจจุบันคือ TLS
  • TLS ทำให้ไคลเอนต์และเซิร์ฟเวอร์ตรวจสอบตัวตนของกันและกัน และเข้ารหัส payload ในรูปแบบที่ทั้งสองฝั่งถอดรหัสได้
  • ลำดับการทำงานของคำขอ HTTPS เหมือนกับคำขอ HTTP ที่กล่าวไปก่อนหน้า เพียงแต่มีการเพิ่ม Security layer ระหว่าง Application layer และ Transport layer
    • โดยทั่วไป TLS handshake จะใช้ TCP

สิ่งที่ TLS handshake ตกลงร่วมกัน

  • TLS handshake คือกระบวนการที่ไคลเอนต์และเซิร์ฟเวอร์ตกลงองค์ประกอบหลายอย่างที่จะใช้ในการสื่อสาร
  • สิ่งที่ตกลงกันรวมถึงชุดอัลกอริทึมที่จะใช้สำหรับการตรวจสอบข้อความ การบีบอัด และการเข้ารหัส
  • ชุดอัลกอริทึมนี้เรียกว่า cipher suite
    • ถ้าพูดอย่างเคร่งครัด cipher suite จะไม่รวม compression algorithm แต่ในบทความนี้จะเรียกรวมทั้งหมดว่า cipher suite
  • ตัวอย่างองค์ประกอบมีดังนี้
    • Compression algorithm: วิธีบีบอัดข้อมูลบน wire เช่น Gzip และ Brotli โดยปัจจุบันมักใช้ Brotli เป็นหลัก
    • Key exchange algorithm: วิธีแลกเปลี่ยนกุญแจเข้ารหัสอย่างปลอดภัยผ่านช่องทางสาธารณะ เช่น ECDHE-RSA และ ECDHE-ECDSA โดยปัจจุบันมักใช้ ECDHE เป็นหลัก
    • Authentication algorithm: วิธีรับรองตัวตนของคู่สื่อสารระหว่าง handshake เช่น RSA และ ECDSA โดย RSA ยังใช้แพร่หลาย และ ECDSA ก็ได้รับความนิยมมากขึ้น
    • Symmetric encryption algorithm: วิธีเข้ารหัสข้อมูลระหว่างไคลเอนต์และเซิร์ฟเวอร์ เช่น AES-128-GCM และ AES-256-GCM โดย AES-GCM ให้ทั้งความปลอดภัยที่แข็งแรงและประสิทธิภาพที่ดี
    • MAC algorithm: วิธีรับประกันความสมบูรณ์และความแท้จริงของข้อความ เช่น HMAC-SHA256 และ HMAC-SHA384 โดยมีการใช้ HMAC-SHA256 และ GCM mode ของ cipher suite รุ่นใหม่
  • ไคลเอนต์และเซิร์ฟเวอร์จะตกลง cipher suite และแลกเปลี่ยน random seed กับข้อมูล SSL certificate เพื่อสร้าง กุญแจแบบสมมาตร ที่จะใช้เข้ารหัสและตรวจสอบข้อความ
  • แหล่งที่มาของข้อมูล TLS handshake คือ Cloudflare

ขั้นตอนของ TLS handshake แบบเดิม

  • Client Hello

    • ไคลเอนต์ส่งข้อความ TCP ไปยังเซิร์ฟเวอร์ ซึ่งประกอบด้วย cipher suite ที่รองรับ, TLS version ที่รองรับ, และค่าตัวเลขสุ่มชื่อ Client Random

  • Server Hello

    • เซิร์ฟเวอร์ตอบกลับด้วยข้อความ TCP ที่มี TLS version ที่เลือกแล้ว, อัลกอริทึม cipher suite ที่เลือกแล้ว, และ Server Random

  • Certificate Verification

    • ไคลเอนต์ตรวจสอบ SSL certificate ของเซิร์ฟเวอร์ผ่าน Certificate Authority และดึง public key ของเซิร์ฟเวอร์มา

  • Premaster Secret Generation

    • ไคลเอนต์สร้าง premaster secret แล้วเข้ารหัสด้วย public key ของเซิร์ฟเวอร์ก่อนส่งไปให้เซิร์ฟเวอร์

  • Decryption

    • เซิร์ฟเวอร์ใช้ private key ถอดรหัส premaster secret

  • Session Key Creation

    • ไคลเอนต์และเซิร์ฟเวอร์ใช้ Client Random, Server Random, และ premaster secret เพื่อสร้าง session key

  • Client Ready

    • ไคลเอนต์ส่งข้อความ finished ที่เข้ารหัสด้วย session key

  • Server Ready

    • เซิร์ฟเวอร์ส่งข้อความ finished ที่เข้ารหัสด้วย session key

  • Secure HTTP Communication

    • หลังจากนั้นทั้งสองฝั่งจะสื่อสารกันด้วยการเข้ารหัสแบบสมมาตรที่ปลอดภัย โดยใช้ session key

สิ่งที่เปลี่ยนไปใน TLS 1.3

  • TLS handshake ที่อธิบายก่อนหน้านี้เป็นกระบวนการของ TLS เวอร์ชันเดิม และถือว่าเป็นวิธีแบบเก่าเมื่อเทียบกับ TLS 1.3 รุ่นปัจจุบัน
  • TLS 1.3 ขึ้นไปไม่รองรับ RSA และ cipher suite หลายแบบอีกต่อไปด้วยเหตุผลด้านความปลอดภัย
  • เวอร์ชันใหม่ลดตัวเลือกลงอย่างมาก จึงเรียบง่ายกว่า ปลอดภัยกว่า และเร็วกว่า
  • แนวคิดหลักยังคงเดิมใน TLS 1.3
    • มีการตกลงเรื่องวิธีบีบอัด การยืนยันตัวตนของเซิร์ฟเวอร์ และการแลกเปลี่ยนกุญแจผ่าน handshake
    • มีการสร้างกุญแจเข้ารหัสแบบสมมาตรเพื่อปกป้องข้อมูลแพ็กเก็ตที่แลกเปลี่ยนผ่าน TCP
  • TLS 1.3 ไม่รองรับ cipher suite และพารามิเตอร์ที่เสี่ยงต่อการโจมตี และลดขั้นตอนของ handshake ให้สั้นลง จึงได้ handshake ที่เร็วและปลอดภัยกว่า

  • ขั้นตอนพื้นฐานของ TLS 1.3 handshake

    • Client hello: ไคลเอนต์ส่งเวอร์ชันของโปรโตคอล, Client Random, และรายการ cipher suite
      • ใน TLS 1.3 การรองรับ cipher suite ที่ไม่ปลอดภัยถูกตัดออก ทำให้จำนวน cipher suite ที่เป็นไปได้ลดลงมาก
      • ใน Client hello ยังมีพารามิเตอร์ที่จะใช้คำนวณ premaster secret ด้วย
      • ไคลเอนต์ตั้งสมมติฐานว่าเซิร์ฟเวอร์รู้ key exchange method ที่ตนต้องการ ซึ่งมีโอกาสสูงขึ้นจากการที่รายการ cipher suite สั้นลง
      • โครงสร้างนี้ทำให้ความยาวรวมของ handshake สั้นกว่า handshake ของ TLS 1.0, 1.1 และ 1.2
    • Server generates master secret: เซิร์ฟเวอร์ได้รับ Client Random, พารามิเตอร์จากไคลเอนต์, และ cipher suite แล้ว และสามารถสร้าง Server Random เองได้ จึงสร้าง master secret ได้
    • Server hello and Finished: ใน Server hello จะมี server certificate, digital signature, Server Random, และ cipher suite ที่เลือก
      • เนื่องจากเซิร์ฟเวอร์มี master secret อยู่แล้ว จึงส่งข้อความ Finished มาพร้อมกันได้เลย
    • Final steps and client Finished: ไคลเอนต์ตรวจสอบ signature และ certificate จากนั้นสร้าง master secret แล้วส่งข้อความ Finished
    • Secure symmetric encryption achieved: หลังจากนั้นก็จะได้การเข้ารหัสแบบสมมาตรที่ปลอดภัย

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-05-27
ความคิดเห็นจาก Hacker News

  • ในฐานะคนที่ไม่ใช่ผู้เชี่ยวชาญ ผมสงสัยว่าทำไมเวลาที่เข้าเว็บไซต์ใดเว็บไซต์หนึ่งหรือใช้อินเทอร์เน็ตทั้งหมดไม่ได้ ถึงรู้ได้ยากขนาดนี้ว่า ความขัดข้องเกิดขึ้นที่ช่วงไหน
    มักไม่ชัดเจนว่าเป็นข้อผิดพลาดในการตั้งค่าเครือข่ายของเครื่องผมเอง, ปัญหาการเชื่อมต่อ Wi‑Fi ไปถึงเราเตอร์, ปัญหาสายระหว่างเราเตอร์กับ ISP, เหตุขัดข้องขนาดใหญ่ของ ISP, หรือเว็บไซต์ที่พยายามเข้าเกิดล่ม
    เคยได้ยินคำอธิบายแบบกว้าง ๆ ว่าเป็นเพราะคำขอถูกส่งไปตามเส้นทางที่ไม่กำหนดแน่นอน แต่ก็ยังไม่ค่อยน่าเชื่อเท่าไร เลยสงสัยว่า ถ้าลิงก์ใดลิงก์หนึ่งระหว่างทางขาด ลิงก์สุดท้ายที่ยังปกติจะส่งข้อความย้อนกลับมาบอกไม่ได้หรือว่า “ข้อความของคุณมาถึงตรงนี้แล้ว แต่พยายามส่งต่อไปขั้นถัดไปแล้วล้มเหลว”

    • ถ้ารู้หลักการทำงาน ก็สามารถหาคำตอบได้ว่าอะไรล้มเหลวกันแน่ แต่การสร้าง เครื่องมือวินิจฉัย ที่ให้คำอธิบายที่เป็นประโยชน์กับผู้ใช้นั้นแทบเป็นไปไม่ได้
      การตั้งค่าแต่ละที่ไม่เหมือนกัน ไม่รู้ได้ว่า configuration แบบไหนเป็นสิ่งที่ตั้งใจไว้ และถ้าเดาจากสาเหตุที่พบบ่อยแล้วให้คำตอบที่ผิดไปโดยสิ้นเชิงก็อันตราย
      ตัวอย่างเช่น ถ้า DNS server ก็ไม่ตอบสนอง และ target host ก็ไม่ตอบสนอง อาจบอกได้ว่าเป็นการตั้งค่าเราเตอร์ผิดหรือ ISP ล่ม แต่สาเหตุจริงอาจเป็น VPN client ที่เปลี่ยน local routing table กับ DNS server แล้วตอนปิดไม่สามารถเปลี่ยนกลับได้ ประเด็นคือเครื่องมือวินิจฉัยจะรู้ได้อย่างไรว่านั่นเป็นการเปลี่ยนแปลงชั่วคราวหรือการตั้งค่าถาวร
    • ถ้าอนุญาตให้ ICMP เข้ามาในเครือข่ายได้ ก็มีโอกาสสูงที่จะได้รับคำตอบ Destination Unreachable จากโฮสต์ที่ไม่สามารถส่งต่อแพ็กเก็ตได้อีก
      แอปพลิเคชันจะมองไม่เห็นข้อความ ICMP เว้นแต่จะตั้งค่า socket ไว้แบบนั้น สิ่งเหล่านี้ถูกปฏิบัติเป็นข้อผิดพลาดแบบ “ชั่วคราว” และใน Linux ตั้งค่าด้วย socket option IP_RECVERR
      เมื่อต้องทำงานที่เลเยอร์ 7 การเก็บข้อผิดพลาดของเลเยอร์นี้ไม่ได้มีคุณค่ามากนัก ข้อผิดพลาด Destination Unreachable ที่โผล่ขึ้นมาด้านบนจะถูกปรับให้เข้ากับ logic การจัดการความล้มเหลวที่มีอยู่แล้ว และในกรณีนี้เลเยอร์อื่น ๆ จะ retry ไปยังปลายทางที่เข้าถึงไม่ได้ จึงน่าจะดูเหมือน timeout
      RFC เหล่านี้ช่วยอธิบายว่าเลเยอร์ TCP จัดการข้อผิดพลาด ICMP อย่างไร: https://www.rfc-editor.org/rfc/rfc1122#page-103
      ในข้อ 4.2.3.9 ระบุว่า เนื่องจากข้อความ Unreachable เป็นเงื่อนไขแบบ soft error ดังนั้น TCP ไม่ควรตัดการเชื่อมต่อ และควรส่งข้อมูลนั้นให้แอปพลิเคชัน TCP อาจส่งขึ้นไปยังเลเยอร์แอปพลิเคชันผ่าน routine ERROR_REPORT หรือบันทึกข้อความไว้แล้วรายงานให้แอปพลิเคชันเฉพาะเมื่อการเชื่อมต่อ TCP timeout เท่านั้น
      ยังมีเอกสารที่ลงรายละเอียดมากขึ้นว่า stack ต่าง ๆ โต้ตอบกันอย่างไร เพื่อศึกษาว่า ICMP เป็น attack vector ต่อ TCP ได้อย่างไร: https://www.rfc-editor.org/rfc/rfc5927
    • เบราว์เซอร์จะรายงานข้อผิดพลาดที่ใกล้เคียงที่สุดกับสิ่งที่กำลังทำอยู่ในตอนนั้น ถ้าหาโฮสต์ไม่พบ ก็หมายความใกล้เคียงว่าเข้าถึง DNS server ได้แล้ว และ server นั้นตอบกลับว่าไม่มี address สำหรับชื่อนั้น
      ถ้าเข้าถึง DNS server เองไม่ได้ ก็เป็นข้อผิดพลาดของเครือข่ายบางอย่างระหว่างผู้ใช้กับ server นั้น ปกติจะวินิจฉัยโดยทำแต่ละขั้นเอง ตรวจว่า ping ไปยัง address ของ DNS server ได้ไหม, ใช้ DNS server นั้น resolve โฮสต์ดังกล่าวได้ไหม, แล้วถ้าใช้ DNS server อื่นเป็นอย่างไร ชื่อบางชื่ออาจถูกยกเว้นเพราะนโยบายของบริษัทก็ได้
      ถ้าอยากเจาะลึกต่อ เครื่องมือ command line อย่าง ping, traceroute, dig ก็มีประโยชน์
    • ปัญหาประเภทนี้จำนวนไม่น้อยแก้กันด้วยการรัน MTR ไปยังปลายทางตอน troubleshooting เพื่อดูรายละเอียดของแต่ละ hop
      MTR เหมือน ping + traceroute ที่ทำงานต่อเนื่องแบบ real-time และแสดงแต่ละ hop แยกกัน
      ตอนที่เริ่มสังเกตเห็นว่า node ในเครือข่าย Xfinity ตาย ก็ยังสอดคล้องกัน เพราะใน MTR เดียวกันอย่างน้อยก็เห็นได้ว่าเครือข่ายของผมไปจนถึงโมเด็มยังปกติ ผมไม่ค่อยเห็นเครื่องมือจำนวนมากที่แสดงการเพิ่มขึ้นของ latency เป็นหลายร้อย ms ที่ hop ใด hop หนึ่งเกิน ISP ได้ดีเท่า MTR
      มันแก้ไม่ได้ทุกปัญหา แต่ให้ latency แยกตาม hop จึงคุ้มค่าที่จะลองตรวจดู
    • สำคัญว่าคุณพยายามตรวจด้วยอะไร แม้เว็บเบราว์เซอร์จะเข้า URL ไม่ได้แต่ไม่บอกสาเหตุที่แน่ชัด ก็เพราะการวินิจฉัยอาจผิดได้ และผู้ใช้ส่วนใหญ่จะสับสน
      การจะพูดว่า “ปัญหาอยู่ตรงนี้” ต้องอาศัยสมมติฐานเกี่ยวกับวิธีที่ระบบปฏิบัติการ ฮาร์ดแวร์ และเครือข่ายถูกกำหนดค่าไว้
      เวลาเข้าเว็บไซต์ ก่อนอื่นต้องรับ IP address ของเว็บเซิร์ฟเวอร์จาก DNS แต่แค่เบราว์เซอร์ได้ DNS IP มาจากไหนก็ซับซ้อนแล้ว อาจตั้งค่าไว้ในเบราว์เซอร์, ระบบปฏิบัติการ, เราเตอร์, โมเด็ม หรือถ้าไม่ได้ตั้งค่าไว้ ก็รับจาก DHCP server ที่เราเตอร์เชื่อมต่ออยู่ ซึ่งอาจเป็น DHCP server ของ ISP หรือเราเตอร์อื่นภายในองค์กรก็ได้
      ถ้า DNS ดูผิดปกติ การรู้ว่า IP ผิดนั้นทำได้ง่าย แต่การบอกว่า IP นั้นมาจากไหนทำได้ยาก SSL ก็เช่นกัน อาจเป็นใบรับรองของเซิร์ฟเวอร์ที่ผิด หรือใบรับรองในคอมพิวเตอร์ของผมที่ผิดก็ได้

  • อาจเกี่ยวข้องกัน มี ตัวอย่างแบบ interactive ที่ไล่ตามอย่างละเอียดระดับ byte สำหรับ TLSv1.2 และ TLSv1.3 ด้วย
    ถ้าอยากเรียนรู้ TLS เพิ่ม นี่เป็นแหล่งข้อมูลที่ผมชอบมากและขอแนะนำอย่างยิ่ง
    [0]: https://tls12.xargs.org/
    [1]: https://tls13.xargs.org/

  • อยากรู้ว่ามีตัวอย่างบทความที่เขียนจากมุมมองแบบนี้อีกไหม ชอบบทความที่อธิบายแบบ “เหมือนอธิบายให้วิศวกรระดับพอใช้ได้ฟัง” โดยไม่เกี่ยวกับระดับความชำนาญ
    โดยรวมแล้วมีประโยชน์มาก เพราะได้เรียนรู้ชิ้นส่วนที่ก่อนหน้านี้ยังไม่ชัดเจนทั้งหมด หรือได้ตัวอย่างเพิ่มเติมไว้ใช้อธิบายให้คนอื่นฟัง

  • คำอธิบายว่า “ไคลเอนต์สร้าง premaster secret แล้วเข้ารหัสด้วย public key ของเซิร์ฟเวอร์ ก่อนส่งไปให้เซิร์ฟเวอร์” นั้นไม่เป็นความจริงมานานแล้ว

    • ด้านล่างมีเขียนไว้ว่า “ทุกสิ่งที่เรียนรู้ตรงนี้เป็นเรื่องโกหก”
      พร้อมเสริมว่ากระบวนการที่เพิ่งอธิบายไปเป็นกระบวนการของ TLS เวอร์ชันแรก ๆ ที่ล้าสมัยเมื่อเทียบกับ TLS 1.3 สมัยใหม่

  • คำว่า “TLS เวอร์ชันปัจจุบัน (>1.3) ไม่รองรับ RSA และ cipher suite หลายแบบด้วยเหตุผลด้านความปลอดภัย” นั้นถูกต้องในส่วนของ การแลกเปลี่ยนคีย์ เพราะ RSA ไม่ให้คุณสมบัติ forward secrecy
    แต่ RSA ยังถูกใช้สำหรับลายเซ็นอยู่ และน่าจะเป็นชนิดที่แพร่หลายที่สุดในใบรับรอง x509
    เท่าที่รู้ Safari ก็เพิ่งเพิ่มข้อกำหนดคีย์ 2048 บิตสำหรับลายเซ็น RSA เมื่อไม่นานมานี้

  • บทความนี้อ่านแล้วเหมือน AI สรุป บทความอธิบาย HTTPS จริง ๆ ศัพท์ต่าง ๆ โผล่มาโดยไม่มีบริบท
    ไม่ได้อธิบายว่าใบรับรองคืออะไร หรือ trust chain ทำงานอย่างไร และสมมติว่าผู้อ่านรู้จักการเข้ารหัสแบบ public key อยู่แล้ว อธิบาย 6 จาก 7 ชั้นของ OSI แต่ไม่พูดคำศัพท์นั้นเอง และขาด presentation layer ไป
    แน่นอนว่าตั้งแต่ชื่อเรื่องก็เรียกว่า mediocre อยู่แล้ว

    • ถ้าจะพูดอย่างเป็นธรรม ก็ไม่ได้ใส่ session layer มาด้วยเหมือนกัน
      การเขียนไม่ใช่จุดแข็งของผม ดังนั้นรับคำวิจารณ์ด้วยความขอบคุณ การที่งานเขียนของผมขยับจาก “แย่” ไปเป็น “AI หรือเปล่า?” ก็ถือว่าเป็นพัฒนาการ
      ผมคิดอยู่เหมือนกันว่าจะตัดคำอธิบายตรงไหน และมองว่าการเข้ารหัสแบบ public key เป็นเส้นแบ่งที่ดี เพราะที่อื่นอธิบายเรื่องนี้ได้ดีกว่า ชั้นต่าง ๆ ของ OSI ก็เช่นกัน
      ยอมรับว่าควรพูดถึงใบรับรอง และอาจรวมถึง trust chain ทั้งหมดด้วย

  • หาโค้ดที่แสดง การตรวจสอบลายเซ็น ของ SHA256(client_hello_random + server_hello_random + curve_info + public_key) ไม่เจอ
    เข้าใจทฤษฎี แต่พอลอง implement แล้วมีอะไรบางอย่างติดขัด ถ้ามีลิงก์โปรแกรมของเล่นที่แสดงว่าจริง ๆ ต้องทำอย่างไรก็คงดี

  • หวังว่าคงไม่ได้หมายความทำนองว่า “มี private key อยู่ในใบรับรอง SSL ของเซิร์ฟเวอร์” นะ แต่ชื่อเรื่องก็เป็น “Mediocre Engineer” จริง ๆ
    TLS <1.3 เองก็ไม่ได้ทำงานแบบที่บทความบรรยายไว้ แล้วก็ยังพยายามเอาองค์ประกอบที่ใหม่กว่าของ 1.3 มาผสม ส่วน DNS อธิบาย recursive resolver แต่ไคลเอนต์ไม่ได้ทำแบบนั้น และน่าจะคุยกับ stub resolver มากกว่า
    มีข้อผิดพลาดโผล่มาเรื่อย ๆ เช่น “Internet Layer”, การสื่อเป็นนัยว่า brotli เป็นอัลกอริทึมที่ใช้กันแพร่หลายใน TLS compression หรือ cipher suite, และ “TLS เวอร์ชันปัจจุบัน (>1.3) ไม่รองรับ RSA”
    บล็อกสแปม แบบนี้ทำให้บางครั้งก็อยากให้มีปุ่ม downvote โฆษณายังไม่น่ารำคาญพอจะ flag แต่คุณภาพต่ำ บางทีผมอาจควรเขียนบทความที่ mediocre น้อยกว่านี้แล้วดันขึ้นหน้าแรก HN เอง ถ้าได้เงินเดือน $300K ก็คงมีเวลามากกว่านี้

  • เนื้อหาในบทความโดยรวมค่อนข้างล้าสมัยเล็กน้อย ทุกวันนี้คำขอเว็บ 30% เป็น HTTP/3 และยังมี CORS ด้วย แต่ไม่มีวันที่เผยแพร่

    • หมายถึง 30% ของคำขอเป็น CORS เหรอ? น่าจะขึ้นกับประเภทงานที่พัฒนาอย่างมาก
      ปกติผมพัฒนาระบบ SaaS ที่ deploy ภายในเครือข่ายองค์กร และคำขอ CORS แทบจะใกล้ 0% เลย HTTP/3 ก็เช่นกัน