คู่มือ HTTPS สำหรับวิศวกรทั่วไป

 (devonperoutky.super.site)
6 คะแนน โดย GN⁺ 2024-05-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

วงจรชีวิตของคำขอ HTTP

1. ไคลเอนต์ส่งคำขอ

  • สร้างคำขอ HTTP: ไคลเอนต์ (โดยปกติคือเว็บเบราว์เซอร์) สร้างคำขอ HTTP
  • เมธอด HTTP: GET, POST เป็นต้น
  • รีซอร์สที่ร้องขอ: เช่น /index.html
  • เวอร์ชันโปรโตคอล: เช่น HTTP/1.1
  • เฮดเดอร์และบอดี: มีเฮดเดอร์ในรูปแบบ key: value และเนื้อความของข้อความซึ่งอาจมีหรือไม่มีก็ได้

2. การค้นหา DNS

  • แปลงชื่อโดเมน: แปลงชื่อโดเมนที่มนุษย์อ่านได้ (www.example.com) ให้เป็นที่อยู่ IP (93.184.216.34)
  • คิวรีไปยังเซิร์ฟเวอร์ DNS: ไคลเอนต์ส่งคิวรีไปยังเซิร์ฟเวอร์ DNS เพื่อแปลงชื่อโดเมนเป็นที่อยู่ IP

3. TCP Handshake

  • ตั้งค่าการเชื่อมต่อ TCP: ไคลเอนต์สร้างการเชื่อมต่อ TCP กับเซิร์ฟเวอร์
  • 3-way handshake:
    • SYN: ไคลเอนต์ส่งคำขอเชื่อมต่อ
    • SYN-ACK: เซิร์ฟเวอร์ยืนยันคำขอ
    • ACK: ไคลเอนต์ส่งการตอบกลับเพื่อยืนยัน

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

  • ส่งคำขอ HTTP: เมื่อสร้างการเชื่อมต่อ TCP แล้ว ไคลเอนต์จะส่งคำขอ HTTP จริง

5. การกำหนดเส้นทางแพ็กเก็ตผ่านอินเทอร์เน็ต

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

6. การตอบสนองของเซิร์ฟเวอร์

  • สร้างการตอบสนอง HTTP: เซิร์ฟเวอร์ประมวลผลคำขอ HTTP และสร้างการตอบสนอง
  • เนื้อหาของการตอบสนอง:
    • โปรโตคอล: เวอร์ชัน HTTP ที่ใช้
    • ข้อมูลสถานะ: รหัสสถานะ HTTP (เช่น 200, 404)
    • เฮดเดอร์การตอบสนอง: คล้ายกับเฮดเดอร์ของคำขอ
    • บอดีการตอบสนอง: คอนเทนต์ที่ร้องขอ (เช่น หน้า HTML, ข้อมูล JSON)

7. การเรนเดอร์คอนเทนต์

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

HTTPS = HTTP + การเข้ารหัส

TLS Handshake

  • TLS handshake: ไคลเอนต์และเซิร์ฟเวอร์แลกเปลี่ยนคีย์สำหรับการเข้ารหัสและการยืนยันตัวตน
  • การสื่อสารแบบเข้ารหัส: หลังจาก TLS handshake แล้ว ไคลเอนต์และเซิร์ฟเวอร์จะใช้ HTTP เพื่อรับส่งข้อความที่เข้ารหัส

TLS 1.3 Handshake

  • กระบวนการที่เรียบง่ายขึ้น: TLS 1.3 มีตัวเลือกน้อยลง จึงง่ายกว่า ปลอดภัยกว่า และเร็วกว่า
  • ขั้นตอนสำคัญ:
    • Client Hello: ไคลเอนต์ส่งชุดการเข้ารหัสและเวอร์ชัน TLS ที่รองรับไปยังเซิร์ฟเวอร์
    • Server Hello: เซิร์ฟเวอร์ส่งชุดการเข้ารหัสและเวอร์ชัน TLS ที่เลือกกลับไปยังไคลเอนต์
    • การตรวจสอบใบรับรอง: ไคลเอนต์ตรวจสอบใบรับรอง SSL ของเซิร์ฟเวอร์
    • การสร้าง premaster secret: ไคลเอนต์สร้าง premaster secret และส่งไปยังเซิร์ฟเวอร์
    • การสร้าง session key: ไคลเอนต์และเซิร์ฟเวอร์สร้าง session key
    • การสื่อสารอย่างปลอดภัย: ใช้ session key เพื่อสื่อสารผ่านการเข้ารหัสแบบสมมาตรอย่างปลอดภัย

ความเห็นของ GN⁺

  • ทำความเข้าใจการสื่อสารบนอินเทอร์เน็ต: การเข้าใจแนวคิดพื้นฐานของ HTTP และ HTTPS ช่วยวางรากฐานด้านการสื่อสารเครือข่ายได้ดี
  • ความสำคัญของความปลอดภัย: การเพิ่มความปลอดภัยของการส่งข้อมูลผ่าน HTTPS เป็นสิ่งสำคัญ
  • ข้อดีของ TLS 1.3: แนะนำให้ใช้ TLS 1.3 ที่เรียบง่ายกว่า เร็วกว่า และปลอดภัยกว่า
  • การนำไปใช้จริง: ในโปรเจ็กต์จริงควรใช้ HTTPS เพื่อเสริมความปลอดภัย
  • การเรียนรู้เพิ่มเติม: การศึกษาชั้นเครือข่ายและโปรโตคอลเพิ่มเติมจะช่วยให้เข้าใจได้ลึกซึ้งยิ่งขึ้น

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

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

 
GN⁺ 2024-05-27
ความคิดเห็นบน Hacker News
  • มีคำถามว่าทำไมเมื่อเกิดปัญหาเครือข่ายจึงยากที่จะรู้ว่าปัญหาเกิดขึ้นตรงไหน โดยมองว่าคำอธิบายที่ว่าเส้นทางเครือข่ายไม่เป็นแบบกำหนดตายตัวนั้นยังไม่ค่อยน่าเชื่อถือ
  • มีความเห็นแนะนำตัวอย่างแบบละเอียดและโต้ตอบได้เกี่ยวกับ TLSv1.2 และ TLSv1.3 พร้อมลิงก์
  • มีความเห็นว่าคำอธิบายสไตล์ "ELI(a mediocre engineer)" มีประโยชน์ และอยากหาตัวอย่างเพิ่มเติม
  • มีคนขอตัวอย่างโค้ดสำหรับตรวจสอบลายเซ็น SHA256 โดยบอกว่ารู้ทฤษฎีแต่ยังลำบากตอนลงมือทำจริง
  • มีความเห็นว่าช่วงที่บอกว่าสามารถได้เงินเดือน $300K จากการเขียน HTTP request ในซานฟรานซิสโกเป็นส่วนที่ดีที่สุดของบทความ
  • มีความเห็นว่าการที่ไคลเอนต์เข้ารหัส pre-master secret ด้วย public key ของเซิร์ฟเวอร์แล้วส่งไปนั้นเป็นข้อมูลเก่าแล้ว
  • มีข้อสงสัยกับคำอธิบายที่ว่าใบรับรอง SSL มี private key รวมอยู่ด้วย และมองว่านี่ก็สมกับชื่อเรื่อง "Mediocre Engineer"
  • มีการล้อเล่นว่าอยากทำงานโดยรับเงินเดือนน้อยลง $50K และมีการชี้ว่าคำอธิบายเกี่ยวกับ TLS <1.3 นั้นผิด
  • มีความเห็นว่าเนื้อหาบทความเก่าแล้ว และปัจจุบัน 30% ของเว็บรีเควสต์ใช้ HTTP3 และ CORS พร้อมทั้งชี้ว่าบทความไม่มีวันที่เผยแพร่
  • มีความเห็นว่าคำอธิบาย HTTPS ดูเหมือนสรุปโดย AI อธิบายศัพท์ไม่พอ และตั้งสมมติฐานว่าผู้อ่านรู้เรื่องการเข้ารหัสกุญแจสาธารณะอยู่แล้ว พร้อมชี้ว่าคำอธิบายเรื่องชั้น OSI ยังไม่สมบูรณ์