อธิบายการทำงานของ HTTPS และเทคโนโลยีที่เกี่ยวข้อง แบบพยายามไม่ให้งง

ช่วงที่ผ่านมานี่เหมือนกระแสเรื่อง HTTPS ค่อนข้างมาแรง ทั้งแรงผลักดันจากภาคเอกชน และเพราะข่าวของรัฐบาล ผมเองเคยศึกษาเรื่องนี้มาบ้างเหมือนกันครับ ยอมรับว่างงมากตอนพยายามศึกษาใหม่ ๆ สุดท้ายพบว่า เราไม่สามารถเข้าใจการทำงานของ HTTPS ได้ ถ้าเราไม่รู้เรื่องเทคโนโลยีที่เกี่ยวข้องกับมัน เลยคิดว่าอยากลองอธิบายในแบบของตัวเองดูครับ และเป็นสรุปเอาไว้อ่านเองด้วยครับ

ต้องบอกก่อนว่าผมไม่ใช่ผู้เชี่ยวชาญด้าน security อะไรนะครับ (จริง ๆ เรื่องนี้ออกแนว security 101 อะไรแบบนั้นด้วยครับ 55) ผิดพลาดประการใดโปรดชี้แนะครับ และ definition ทั้งหลายใน blog นี้คือไม่ใช่ official definition จากองค์กรไหนนะครับ

ยาวไปไม่อ่าน

  • HTTPS เป็น protocol สำหรับส่งข้อมูลที่มีการเข้ารหัส (encrypt) ไปตาม network ซึ่งจะมีแค่ผู้รับเท่านั้นที่ถอดรหัส (decrypt) ได้ โดยอาศัย SSL/TLS protocol ทำให้ข้อมูลของเราปลอดภัย และเว็บไซต์น่าเชื่อถือมากขึ้น
  • HTTPS ทำงานโดยอาศัยสิ่งที่เรียกว่า Digital certification (SSL certification) ซึ่งเทคโนโลยีนี้อาศัย Digital signature (ลายเซ็นอิเล็กทรอนิกส์)
  • ซึ่ง Digital Signature นี้ก็อาศัยความรู้เรื่อง cryptography เช่น hashing, encrypt, decrypt
  • จึงเป็นสาเหตุให้ blog นี้จะเกริ่นมาตั้งแต่ cryptography

การเข้ารหัส (Cryptography)

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

Cryptography ประกอบด้วย 2 ส่วนคือ Encryption (เข้ารหัส) และ Decryption (ถอดรหัส) การจะ encrypt กับ decrypt จะต้องใช้ key ในการดำเนินการ ดังนั้นเราจึงแบ่ง cryptography ได้เป็น 2 กลุ่มตามรูปแบบ key ที่ใช้ คือ Symmetric cryptography กับ Asymmetric cryptography

Symmetric Cryptography

ก็คือคน encrypt กับคน decrypt ใช้ key ตัวเดียวกัน

Symmetric Cryptography

จากรูปข้างบน แค่ 3 คนยังต้องใช้ 3 key ถ้าจำนวนคนที่ติดต่อสื่อสารมากขึ้น จำนวน key ที่ต้องสร้างมันจะเยอะมาก

จำนวนคนจำนวน key
21
33
1045
1004,950
1,000499,500
10,00049,995,000

Asymmetric Cryptography

ก็คือแต่ละคนจะมี 2 key คือ Public key (เอาไว้แจกให้ชาวบ้าน) และ Private key (เก็บไว้ในเครื่องไม่ต้องไปแจกใคร) เวลา encrypt ก็ใช้ key หนึ่ง เวลา decrypt ก็ใช้อีก key ซึ่งเราสามารถใช้ key ไหนในการ encrypt ข้อมูลก็ได้ แต่จะ decrypt ต้องใช้อีก key ที่คู่กัน

ตัวอย่างเช่น Alice จะส่งข้อมูลหา Bob ก็ encrypt message ด้วย public key ของ Bob (Bob แจกให้ทุกคนเพราะมัน public) แล้วส่ง encrypted message ไป พอ Bob จะเปิดอ่านก็ใช้ private key ของตัวเอง decrypt ก็จะได้ข้อมูลมา

Asymmetric Cryptography

Asymmetric Cryptography ทำให้การสื่อสารระหว่างคนจำนวนมาก ๆ ไม่จำเป็นต้องสร้าง key มาเยอะ ๆ เพราะแต่ละคนสร้างแค่ 2 key (ลองเทียบกับ symmetric ครับจะพบความต่างกันมาก)

จำนวนคนจำนวน key
24
36
1020
100200
1,0002,000
10,00020,000

Encryption Algorithm

ทั้ง symmetric และ asymmetric cryptography จำเป็นต้องอาศัย algorithm ในการ encrypt/decrypt ข้อมูล ซึ่งแต่ละแบบก็จะมี algorithm ให้เลือกมากมาย (ซึ่งหลาย ๆ algorithm ก็ถือว่าไม่ปลอดภัยแล้วในปัจจุบัน)

  • ตัวอย่าง symmetric cryptography algorithm เช่น DES, 3DES, AES, Blowfish, Twofish, RC4 ที่ผมว่าดังสุด และยังถือว่าปลอดภัยในปัจจุบัน น่าจะเป็น AES ครับ
  • ตัวอย่าง asymmetric cryptography algorithm เช่น RSA, PGP, GPG ดังสุดเข้าใจว่าคือ RSA

Asymmetric cryptography มักจะช้ากว่า symmetric ดังนั้นเวลาส่งข้อมูลเยอะ ๆ ผ่าน network เราจึงมักใช้ asymmetric เพื่อเชื่อมต่อและยืนยันตัวตนก่อน หลังจากนั้นแลกเปลี่ยนข้อมูลกันด้วย symmetric ซึ่ง HTTPS ก็ทำแบบนี้ครับ

Public Key Infrastructure (PKI)

คือจากเรื่อง encryption ถ้า Alice จะส่งข้อมูลไปหา Bob สมมติมีคนมาดักข้อมูลไปกลางทางก็ไม่สามารถเปิดได้ เพราะไม่มี key ที่คู่กัน แต่มันจะมีปัญหาใหม่คือ Alice จะรู้ได้อย่างไรว่า public key ที่มีคือของ Bob จริง ๆ ถ้าสมมติมีคนปลอมตัวเป็น Bob แอบเอา public key ของตัวเองมาให้ Alice ถ้าเขาดักข้อมูลที่ Alice ส่งได้ ก็จะ decrypt ได้ (เพราะมี private key ที่คู่กัน)

วิธีการก็คือก่อนจะคุยกัน Bob ต้องมี “ใบรับรองความเป็น Bob” ซึ่งออกโดย “องค์กรที่ Alice เชื่อถือ” และมีวิธียืนยันได้ว่าใบรับรองนั้นเป็นของจริง อันนี้คือทำให้เราต้องมีระบบที่เรียกว่า Public Key Infrastructure (PKI) ครับ แต่ก่อนจะไปถึงตรงนั้น มีคำหนึ่งที่ต้องรู้จักก่อน คือคำว่า Hash function

Hash Function

Hash function คือ function ที่จะเปลี่ยนข้อมูลที่มีความยาวหลากหลาย (variable length input) มาเป็นข้อมูลที่มีความยาวเท่าเดิมเสมอ (fixed-length output) out put นี้เรียกว่า digest

คุณสมบัติของ Hash function

  • One-way function คือทำงานทางเดียว แปลงแล้วแปลงเลย แปลงกลับไม่ได้
  • ไม่ว่า input จะใหญ่ขนาดไหน digest ที่ออกมาจะมีความยาวเท่าเดิมเสมอ
  • ถ้า input ไม่เหมือนกัน แม้เปลี่ยนแค่นิดเดียว (เช่นเปลี่ยนตัวสะกดคำเดียวในไฟล์ Word) digest ที่ออกมาจะไม่เหมือนกันแน่นอน และต่างแบบเดาไม่ได้ว่าอันเดิมคืออะไร อันนี้เรียกว่า collision resistant

ตัวอย่าง hash function ดัง ๆ เช่น MD5 (ไม่ปลอดภัยแล้ว), SHA (สร้างโดย NIST ของเมกา อันนี้น่าจะดังสุด), RIPEMD (บางคนบอก SHA มันของรัฐบาล เชื่อไม่ได้ เลยสร้างอันนี้มา)

Hash function

ระวังอย่าสับสนระหว่าง encryption กับ hash นะครับ อันแรกเข้ารหัสถอดรหัสได้ ส่วนอันหลังแปลงแล้วแปลงเลย ได้ output ความยาวเท่าเดิมเสมอ

Digital Signature

คล้ายกับการที่เราประทับตราบริษัทเวลาเซ็นเอกสารแหละครับ แต่พอเป็น digital ขั้นตอนมันจะซับซ้อนขึ้นมานิด เพราะเราไม่สามารถแค่สร้างตราขึ้นมาแล้วต่อเข้าไปในไฟล์ได้ มันจะก็อปปี้ได้ง่ายเกินไป ดังนั้นวิธีการคือ

  1. นำเอกสารที่เราต้องการส่ง ไปเข้า hash function ได้ digest A ออกมา
  2. นำ digest A ที่ได้ไป encrypt ด้วย private key ของเรา สิ่งที่ได้ออกมาคือ digital signature นี่แหละครับ
  3. เราส่งเอกสารแบบปกติ (ไม่ hash) + digital signature ของเรา + public key ของเราไปไปให้ผู้รับ
Signing a Digital Signature

ทีนี้ถ้าผู้รับจะตรวจสอบว่าเป็น signature ของจริงหรือไม่

  1. ผู้รับจะใช้ public key ของเราในการ decrypt digital signature ซึ่งจะได้ digest A ออกมา
  2. ผู้รับจะเอาเอกสารของเราไปเข้า hash function ซึ่งจะได้ digest B ออกมา
  3. ถ้า digest A และ digest B เหมือนกัน แสดงว่า digital signature นั้นเป็นของจริง
Verifying a Digital Signature

เมื่อผู้รับได้รับข้อมูลที่มี digital signature นี้ ถ้า verify แล้ว valid แสดงว่าข้อมูลนั้น:

  1. ข้อมูลนี้ถูกส่งมาจากเจ้าของ public key จริง ๆ
  2. ไม่มีใครมาแอบเปลี่ยน เพราะถ้าเปลี่ยนข้อมูล hash ใน signature ต้องเปลี่ยนด้วย

Digital signature นี้ไม่ได้มีความเกี่ยวข้องอะไรกับการรักษาความลับนะครับ เน้นพิสูจน์ว่าใครเป็นคนสร้างข้อมูลมากกว่า ถ้าจะรักษาความลับด้วยต้องใช้ร่วมกับวิธีการอื่น ๆ

Digital signature นี้สามารถใช้ใส่ signature ในไฟล์ทุกประเภท Word, PDF, ข้อมูลที่ส่งผ่านเน็ต ฯลฯ เพื่อยืนยัน 2 เรื่องข้างต้น เรื่องหนึ่งที่ใช้กันเยอะ คือรับรอง Digital Certification ครับ

Digital Certification

เหมือนเวลาเราจะติดต่อกับองค์กรต่าง ๆ แล้วเราต้องแสดงบัตรประชาชนเพื่อรับรองตัวตนของเราครับ บนบัตรก็ข้อมูลเกี่ยวกับตัวเรา และมีตราประทับยืนยันความถูกต้อง จากองค์กรที่สังคมเชื่อถือ ในกรณีของ digital certification นี้ก็คือใบรับรองว่าเว็บที่เราสื่อสารอยู่ด้วยนั้นคือเว็บที่เราต้องการจะสื่อสาร ไม่ใช่คนอื่นปลอมตัวมา ซึ่งกระบวนการออก certificate นี้ ก็ต้องการคนที่สังคมเชื่อถือได้ นั่นคือ Certificate Authority (CA) โดยใน certificate จะมี digital signature ของ CA รับรองอยู่

Certificate Authority (CA)

ก็คือองค์กรที่ทำหน้าที่ออก certificate ซึ่งการจะออก certificate ได้เขาก็ต้องตรวจสอบก่อนว่าคนที่ขอเป็นใคร เชื่อถือได้จริงหรือเปล่า เพราะถ้าให้ไปมั่ว ๆ CA นั้นก็จะสูญเสียความน่าเชื่อถือไป (จริง ๆ มี Registration Authority (RA) และอื่น ๆ มาเกี่ยวอีก ตัดไปก่อนละกันครับ)

ขั้นตอนการขอใบรับรอง

  1. ผู้ให้บริการ สร้าง Certificate Signing Request (CSR) และส่ง Public Key ของตัวเองไปให้ CA
  2. CA ตรวจสอบและยืนยันความถูกต้อง
  3. CA ออกใบรับรองให้ โดยเนื้อหาประกอบด้วย ข้อมูลของผู้ให้บริการ, Public key ที่ส่งมา, และรับรองด้วย digital signature ของ CA
  4. ผู้ให้บริการเอาใบรับรองนั้นไปใช้แสดงตัวเวลามีคนสื่อสารด้วย
Certificate Authority certification process

ตัวอย่างการใช้งาน digital certificate ก็เช่น เวลาเราลงโปรแกรมใหม่ในเครื่อง โปรแกรมที่จะลงก็จะมี certificate ติดมา ปกติในเครื่องหรือใน web browser ของเราจะมี public key ของ CA เจ้าหลัก ๆ อยู่แล้ว ก็เอา public key นั้นไปตรวจสอบ signature ใน certificate ถ้าผ่านก็แสดงว่าเป็นโปรแกรมจากบริษัทที่เราต้องการจริง ลงโปรแกรมได้

ตัวอย่าง root CA ที่มากับ MacOS โดย default

หรืออย่างการสื่อสารผ่านอินเตอร์เน็ต เช่น เวลาเราเข้าเว็บ เครื่อง server ก็จะส่ง certificate ไปให้ web browser ดูเพื่อยืนยันตัวตนก่อนเริ่มการสื่อสาร ซึ่งจะทำแบบนี้ได้ ต้องใช้ protocol ที่ชื่อว่า SSL/TLS ดังนั้น certificate สำหรับเว็บนี้คนเลยเรียกอีกชื่อว่า SSL certificate ครับ หรือถ้าเรียกตามชื่อมาตรฐานก็ X.509 certificate

HTTPS และ SSL/TLS

เวลาอุปกรณ์ต่าง ๆ ทำการสื่อสารผ่านระบบเครือข่าย (network) มันจะทำเป็นชั้น ๆ (layer) ทั้งหมด 7 ชั้น (อ้างอิงตาม OSI Model) แต่ละชั้นก็จะมีหน้าที่ของมัน และมี protocol ของสำหรับทำหน้าที่นั้นเยอะแยะมากมาย ซึ่งในการสื่อสารผ่านอินเตอร์เน็ตแบบ secure นี้ อยากโฟกัส 2 ชั้นบนครับคือ:

  • Layer 7 (Application layer): มี HTTPS protocol
  • Layer 6 (Presentation layer): มี SSL/TLS protocol

HTTP protocol ปกติแล้วไม่สามารถ encrypt ข้อมูลได้ครับ ส่งไปไงก็ไปงั้น โดนดักข้อมูลได้ก็จบเลย ถ้าอยากให้ encrypt ได้ต้องไปผ่านอีกชั้น โดยผ่าน SSL/TLS protocol ก็จะปลอดภัยมากขึ้น HTTP protocol ที่สื่อสารผ่าน SSL/TLS นี้เรียกว่า HTTPS

ส่วน SSL (Secure Sockets Layer) และ TLS (Transport Layer Security) ก็เป็น protocol ทั้งคู่ แต่จริง ๆ SSL กับ TLS นี่คนละอันกันนะครับ SSL เกิดก่อน ปัจจุบันถือว่าไม่ปลอดภัยแล้ว TLS เกิดทีหลัง ปัจจุบันยังปลอดภัยอยู่ แต่เรามักจะเรียกกลุ่มนี้รวม ๆ ไปเลยว่า “SSL” ดังนั้น เวลาคนพูดถึง SSL ในปัจจุบัน จริง ๆ เขามักหมายถึง TLS นะครับ

สรุป HTTPS และ SSL/TLS เป็น network protocol ทั้งคู่ ทำงานประสานกัน แต่คนละ layer กัน

HTTPS ทำงานอย่างไร

เกริ่นมานานมากกว่าจะเข้าเรื่องได้ แต่ก่อนจะเล่าได้ต้องนิยามคำหนึ่งก่อน คือ Cipher suite พูดง่าย ๆ Cipher suite ก็คือชุดของข้อตกลงว่า client กับ server จะคุยกันยังไง ใช้ encryption algorithm ไหน hash function อะไร

เมื่อจะเริ่มการสื่อสารต้องมีกระบวนการที่เรียกว่า handshaking ซึ่งมีขั้นตอนคือ

1. Client (web browser ของเรา) ส่ง request ไปยัง server บอกไปว่าตัวเองรองรับ Cipher suite อะไรบ้าง

2. Server ตอบกลับว่าจะใช้ Cipher suite ไหน แล้วก็ส่ง SSL certificate กลับมาด้วย

3. Client เช็คว่า certificate นั้น valid จริงหรือเปล่า ทำได้เพราะ:

  • ใน certificate มี public key ของ server และ digital signature ของ CA
  • ในเครื่องของเรามี public key ของ CA เจ้าดัง ๆ อยู่แล้ว

ดังนั้นก็ตรวจสอบได้ว่า signature นั้นเป็นของจริงหรือเปล่า โดยใช้ public key ของ CA ถ้าจริง certificate นั้นก็น่าจะจริง ดังนั้น public key ของ server ที่อยู่ใน certificate นั้นก็เชื่อถือได้

ถ้าในเครื่องไม่มี public key ของ CA นั้น ก็จะมีวิธีตรวจสอบอื่น ๆ ต่อไป

4. Client สุ่มสร้าง key มาใหม่อันนึง เรียกว่า session key แล้ว encrypt มันด้วย public key ของ server แล้วส่งกลับไปให้ server (server ค่อย decrypt ด้วย private key ของตัวเอง) จากนั้นทั้งสองฝั่งก็ใช้ session key นี้ในการสื่อสาร

อย่างที่กล่าวไปข้างต้นว่า asymmetric cryptography นั้นช้าและไม่เหมาะกับข้อมูลยาว ๆ ดังนั้น session key (ephemeral key) อันนี้เป็น symmetric cryptography ครับ หลักการคือใช้ asymmetric เริ่มการสื่อสาร หลังจากนั้นคุยกันต่อด้วย symmetric

ก่อนที่ขั้น 4 จะเสร็จสิ้น ฝั่ง client ยังไม่ได้ส่งข้อมูลสำคัญอะไรไปให้ server นะครับ server ไม่รู้แม้กระทั่ง url ที่เราจะเข้า เช่น rath.asia/aaa/bbb/ccc/ddd ฝั่ง server ก็จะรู้แค่ว่าเราจะเข้า rath.asia ดังนั้น เมื่อเราสื่อสารผ่าน HTTPS ถ้าไม่มีอะไรผิดพลาด คนอื่นจะไม่รู้เลยว่าเราเข้าเว็บไปดูหน้าไหน

พอการสื่อสารเสร็จเรียบร้อย session key ก็จะถูกทำลายทิ้ง ก็เป็นอันเสร็จสิ้นครับ ทุกอย่างกลับสู่ความสงบสุข

ทำเว็บให้รองรับ HTTPS

ช่วงนี้ก็มีกระแสทำเว็บให้รองรับ HTTPS กันเยอะพอสมควร รวบรวมเว็บไทยที่น่าสนใจมาฝากครับ

รัฐบาลไทยกับ Root CA

ช่วงที่ผ่านมามีข่าวของการค้นพบว่า Microsoft รับรอง Root CA ของรัฐบาลไทยเป็นค่า default เรื่องนี้มีหลายฝ่ายแสดงความเห็นกัน ทั้งเห็นด้วยและไม่เห็นด้วย ฝั่งต่อต้านก็มองว่านี่มันเป็นโอกาสให้รัฐบาลไทยทำ Man-in-the-middle attack ได้เลยนะ (blog เรื่อง basic security threat) รัฐบาลนี้ยิ่งดูมีความพยายามจะทำมาหลายรอบแล้ว ฝ่ายสนับสนุนก็มองว่านี่เป็นการส่งเสริมให้ไทยออกใบรับรองด้วยตนเองได้ ไม่ต้องพึ่งต่างชาติ และอันนี้เขาก็มีกระบวนการ audit ที่เคร่งครัด กว่าจะได้รับการรับรองก็ทำมาตั้งหลายปี เขาไม่เอามาทำเรื่องแบบนี้หรอก

สรุปว่ายาวครับ ใครสนใจลองดูในลิงค์ต่าง ๆ เหล่านี้

เชื่อว่าถ้า Google จริง ๆ ก็คงเจอเยอะกว่านี้ เรื่อง Root CA นี่เป็นเรื่องที่ผมไม่ได้กล่าวถึงใน blog นี้ เพราะมันก็มีรายละเอียดของมัน และผมก็ยังไม่ค่อยมั่นใจเท่าไหร่ว่าตัวเองเข้าใจดี 55 คือเป็นเรื่องของ Public Key Infrastructure (PKI) แหละครับ

อ้างอิง

———————————

ก็จบแล้วครับ หวังว่าจะพอเป็นประโยชน์นะครับ

Comments

  1. ขอเสริมเรื่องวิธีการนับจำนวน Key แบบ Symmetric Cryptography นะครับ

    ผมได้วาดภาพแล้วลองคิดเล่นๆ (เหมือนทำโจทย์เลข) โดยวาดรูปจำลอง แล้วลองนับดู ได้คำตอบว่า จำนวน Key ที่ต้องใช้ทั้งหมด เมื่อจำนวนผู้ใช้คือ n จะเท่ากับผลรวม n-1 + n-2 + .. + 1 และเมื่อประยุกต์ใช้สูตรของ Gauss จะได้ (n * n-1)/2

    ประการละฉะนี้เอิงเอยย

  2. ขอเสริมนิดนึงนะครับ หัวข้อ Certificate Process

    ตามที่ได้กล่าวมา การขอซื้อ SSL กระทำได้โดย ส่ง public key และ CSR

    แต่ในความเป็นจริง ทำไมเว็บต่างๆที่ขาย SSL ถึงให้ส่งแค่ CSR เท่านั้น แล้ว public key ล่ะส่งไปตอนไหน?

    ผมเองก็ขี้สงสัยเลยหาคำตอบมาให้

    มาดูกันภายใน CSR มีอะไรบ้าง

    1.ข้อมูลส่วนตัวของผู้ขอซื้อ SSL เช่น
    – ชื่อโดเมนของ Server
    – หน่วยงาน psucoop
    – ประเทศ ไทย
    และอื่นๆ

    2.public key ของ Server ซึ่งมันจะถูกสร้างขึ้นเองโดยอัตโนมัติ จากการสร้างใบ CSR ด้วย privatekey

    ตัวอย่างคำสั่งสร้าง CSR ของ Ubuntu
    openssl req -new -key privatekey.pem -out csr.pem
    ความหมายของคำสั่งนี้ สร้างใบเซอ (CSR) มาตรฐาน X.509 ใหม่ ด้วย privatekey.pem และส่งผลลัพธ์ออกมาเป็นชื่อไฟล์ csr.pem

    หมายเหตุ การสร้าง privatekey มีหลายวิธีในการสร้าง เช่น สร้างจากหน้าเว็บไซต์,สร้างจากระบบปฎิบัติการ linux , microsoft

  3. ได้ความรู้ อธิบายได้เข้าใจ พอเห็นภาพ สุดยอดครับผม

    1. เนื่องจากผมไม่ใช่ expert ด้าน security เลยไม่ขอตอบเองดีกว่าครับ แฮ่ ๆ แต่ตามลิงค์นี้นะครับ (ถ้า advanced กว่านี้ผมก็ไม่ทราบแล้วเหมือนกันฮะ 55)

      https://security.stackexchange.com/questions/8145/does-https-prevent-man-in-the-middle-attacks-by-proxy-server

    2. ก่อนอื่นขอขอบคุณเนื้อหาดีในบทความนี้ด้วยนะครับ หาอ่านที่เข้าใจแบบนี้ไม่มีเลย
      การป้องการ mitm ด้วย https ต้องมีการตรวจสอบ ca cert สองด้านนะครับ ปกติเวลาเราเข้า website ฝั่ง client จะตรวจสอบว่า server นั้นเป็น server ที่ถูกต้องด้านเดียว ซึ่งไม่ได้ตรวจสอบฝั่ง client จึงสามารถทำ mitm ได้ แต่ถ้า server config ให้มีการตรวจสอบ cert 2 ด้านก็คงไม่สดวกในการใช้งานเพราะ ฝั่ง client ก็ต้องมี certด้วย การตรวจสอบ ca cert สองด้านจึงมักจะทำเป็นกรณีพิเศษที่เป็นกลุ่มเฉพาะ เช่นการ vpn ตรวจสอบ ca cert 2 ด้าน ใครได้ username password ไปก็ยังเข้าไม่ได้ เนื่องจาก ไม่มี cert ที่ถูกต้อง หรือ การเชื่อมต่อกับบริษัท คู่ค้าประมาณนี้ครับ (ตอบตามความเข้าใจนะครับที่ ทำงานมาซึ่งใช้แบบนี้ครับ )

  4. ไม่ทราบว่า มี course เรื่องการ ทำงานของ certificate และ ssl แบบนี้ไหมครับ

    พอดีผมอยากรู้เรื่องพวกนี้เพิ่มเติมครับ

    ถ้ามีรบกวน แจ้งให้หน่อยครับ

    ขอบคุณครับ

    1. จริง ๆ คอร์สที่ผมเรียนก็โอเคนะครับ ที่ Lynda ครับ CompTIA Security+ Exam Prep (SY0-401)

  5. ขอบคุณสำหรับความรู้ค่ะ มีประโยชน์มากๆเลย

  6. ขอบคุณครับ แต่งง ตอน HTTPS ว่า public key ของ CA มันเอาไปเช็คกับ cerfiticate server ส่งมายังไง

    1. ผมเองก็ห่างหายจากวงการนี้ไปนาน จำอะไรไม่ได้แล้วครับ ขออภัยด้วยนะครับ

Leave a Reply

Your email address will not be published. Required fields are marked *