TLS คืออะไร มีที่มาที่ไปอย่างไร การทำงานเป็นอย่างไร ลองมาเรียนรู้ทำความใจเบื้องต้นกันครับ
TLS หรือ Transport Layer Security
เป็นโปรโตคอลที่ใช้เป็นข้อกำหนดมาตรฐานในการโอนย้ายข้อมูล (protocol for secure communication) ถูกออกแบบมาเพื่อเพิ่มความปลอดภัยในการสื่อสารทางเครือข่ายคอมพิวเตอร์ โดยส่วนใหญ่ใช้กับการสื่อสารผ่านทางอินเทอร์เน็ต และมักใช้สำหรับการป้องกันการถูกดักจับ (eavesdropping) และการป้องกันการแทรกแซงข้อมูล (tampering) ในระหว่างการสื่อสาร
TLS เป็นการพัฒนาจาก SSL (Secure Sockets Layer) ซึ่งเป็นเทคโนโลยีที่ให้ความปลอดภัยในการสื่อสารออนไลน์เช่นเดียวกัน แต่มีการปรับปรุงและปรับให้มีความปลอดภัยมากยิ่งขึ้น และถูกนำมาใช้กันอย่างแพร่หลายในการติดต่อสื่อสารที่ใช้โพรโทคอล HTTP (HyperText Transfer Protocol) เพื่อให้การสื่อสารระหว่างเว็บบราวเซอร์และเว็บเซิร์ฟเวอร์เป็นไปอย่างปลอดภัย
ย้อนอดีตที่มาที่ไป
ข้อมูลที่เราเก็บไว้ในคอมพิวเตอร์ของแต่ละคนก็มีความสำคัญแตกต่างกันไป ถ้าข้อมูลนั้นสำคัญมาก เราก็ไม่อยากให้คนอื่นๆที่เราไม่ต้องการให้รู้ ไม่ให้คนอื่นรู้ว่าเรามีข้อมูลอะไรเนื้อหาอย่างไร ไม่ให้คนอื่นมาแก้ไขข้อมูลของเราได้ ถ้าเราไม่อนุญาต
ดังนั้น เราก็ต้องทำการ เข้ารหัส (Encryption) ซึ่งตัวเราเองก็จะมีกุญแจสำหรับ ถอดรหัส (Decryption) เก็บไว้ที่เราเพียงคนเดียว คนอื่นๆที่ไม่มีกุญแจนี้ ก็ไม่สามารถที่จะรู้เห็นข้อมูลของเราได้ เพราะเค้าไม่มีกุญแจ นอกซะจากว่า เราจะให้กุญแจเค้าไป หรือ ถ้าเก่งๆ เค้าอาจปลอมกุญแจของเราขึ้นมาได้ ก็ขึ้นอยู่ว่าคุ้มที่จะทำไหม เพราะการสร้างกุญแจ ที่ใช้เข้ารหัส ,ถอดหรัส ที่ว่านี้มันอยู่ได้ในหลายรูปแบบเช่น
- ข้อความรหัสผ่าน ( Passphrase , Password )
- กุญแจส่วนตัว ( Private key )
- ลายนิ้วมือ / ใบหน้า ( Biometric )
- อุปกรณ์พกพาที่มีฟังก์ชันสำหรับสร้างรหัสยืนยันตัวตนที่ใช้ในการเข้าถึงระบบ ( Hardware Token )
หรืออื่นๆสุดแล้วแต่จะออกแบบได้ ซึ่งการเข้ารหัสนั้น จะว่าปลอดภัยก็ปลอดภัย แต่ถ้ารหัสผ่านจำยาก หรือ ลืมรหัส หรือ รั่วไหล ให้คนอื่นได้ตัวถอดรหัสไป ก็เกิดความเสี่ยงกับข้อมูลของเราได้
จากตัวอย่างรูปด้านบน ผมเข้าทำการเข้ารหัสไฟล์ text ที่ชื่อว่า akenet-test-encrypt ด้วยโปรแกรม PDF Creator Free โดยเลือก Profile เป็น Secure PDF ซึ่งโปรแกรมจะทำการแปลงไฟล์เป็น .pdf ด้วย จากนั้นให้เรากดที่ Edit เพื่อดูการตั้งค่าอื่นๆ
ซึ่งการที่จะให้กุญแจมีรูปแบบซับซ้อนรอยหยักเยอะๆแค่ไหนนั้น ก็ตั้งค่าได้ โดยเลือกตั้งค่าที่เมนู Action -> Modify ในส่วนของ Encryption จะเป็นการเลือกอัลกอริทึ่ม จากตัวอย่างคือใช้ AES-128bit ซึ่งก็ยากระดับนึง ถ้าจะทำให้มันมีรอยหยักของกุญแจซับซ้อนมากขึ้น ก็เลือก AES-256bit ได้ เพราะมันจะทำให้คนอื่นเลียนแบบ หรือ แกะ,ถอด รหัสของเราได้ยากขึ้นนั่นเอง จากนั้นกด Save และกด Save
เมื่อกด Save แล้ว โปรแกรมจะให้ตั้งรหัส สำหรับแก้ไข และ เปิดอ่านได้เพียงอย่างเดียว ซึ่งการใส่ข้อความที่ใช้เป็นรหัสส่วนนี้ ก็จะถูกนำไปเข้ากระบวนการหรือ อัลกอริทึ่ม AES-128 ที่เราตั้งค่าไว้นั่นเองจากนั้นกด Continue เป็นอันเสร็จ
เราจะได้ไฟล์ akenet-test-encrypt เป็น .pdf เมื่อเราทำการเปิดไฟล์ขึ้นมา จะต้องทำการใส่รหัสผ่าน ก่อน ซึ่งก็คือกุญแจ ที่เรามี ที่เรารู้เพียงคนเดียว เพราะเรากำหนดมันขึ้นมาเอง มีเราเท่านั้นที่จะเปิดอ่าน ( Decryption )ไฟล์นี้ได้
ทีนี้การเข้ารหัสไฟล์ข้อมูล หรือ การเก็บข้อมูลเรา ก็จะเข้าหลักการของ CIA ครับ หลักการ CIA (Confidentiality, Integrity, Availability) เป็นหลักการที่ใช้ในด้านความปลอดภัยของข้อมูลและระบบสารสนเทศ
Confidentiality (ความลับ): หมายถึงการรักษาข้อมูลให้ปลอดภัยและไม่สามารถเข้าถึงได้โดยบุคคลที่ไม่มีสิทธิ์. การใช้เทคโนโลยีการเข้ารหัส (encryption) เป็นหนึ่งในวิธีที่มักถูกนำมาใช้เพื่อรักษาความลับของข้อมูล.
Integrity (ความคงสภาพ): หมายถึงความถูกต้องและไม่ถูกแก้ไขข้อมูลโดยไม่ได้รับอนุญาต. มีการใช้วิธีการต่าง ๆ เช่นการสร้าง checksum, digital signature เพื่อตรวจสอบความคงสภาพของข้อมูล.
Availability (ความพร้อมใช้): หมายถึงการรักษาให้บริการหรือข้อมูลพร้อมใช้งานทุกเมื่อที่ผู้ใช้ต้องการ. ถ้าเราเกิดลืมรหัสผ่าน หรือทำกุญแจหายไป หรือ โดนขโมยกุญแจไป ข้อมูลเราก็จะไม่เกิดความพร้อมใช้
ซึ่งที่กล่าวมานั้น เรายังไม่ได้ส่งไฟล์ระหว่างเครื่องคอมพิวเตอร์นะครับ เป็นการกระทำในเครื่องของเราเองไม่ได้ส่งผ่านอินเตอร์เน็ตไปที่ไหน ก็จะเริ่มเห็นกว่าจะเข้ารหัส หรือ ถอดรหัส ได้นั้นมันจะมีความยุ่งยากและใช้เวลามากขึ้นเมื่อจะกระทำการกับข้อมูลนั้นๆเกิดขึ้นได้
ซึ่งถ้าเราใช้เองคนเดียวหรือกลุ่มคนเล็กๆที่เราควบคุมได้แล้วนั้น การเข้ารหัส ก็ไม่จำเป็นที่จะต้องทำกับทุกๆข้อมูลก็ได้ครับ ก็ต้องพิจารณาเป็นอย่างๆไป ตามความเหมาะสมของแต่ละข้อมูลของเรา
ที่ผ่านมาในช่วงปี ค.ศ. 1990–1995 เมื่ออินเตอร์เน็ตเพิ่งเริ่มใช้กันมากขึ้น การรับส่งข้อมูลผ่านคอมพิวเตอร์มีการขยายตัวอย่างมาก แต่มีปัญหาที่อยู่ในหลักการของความปลอดภัย
ในยุคนั้น การสื่อสารนั้นมักจะไม่มีการเข้ารหัสข้อมูลที่ถูกส่งไปมา ซึ่งทำให้มีความเสี่ยงที่ข้อมูลอาจถูกดักจับได้ในระหว่างทาง
ถ้าเราส่งอีเมลผ่านเครือข่ายอินเตอร์เน็ต มีความเป็นไปได้ที่ผู้คนที่มีความสนใจอาจพยายามดักจับข้อมูลนั้น เหตุนี้แสดงให้เห็นถึงความสำคัญของการรักษาความลับของข้อมูลที่รับส่ง โดยการเข้ารหัส เพื่อป้องกันไม่ให้บุคคลที่ไม่มีสิทธิ์เข้าถึงข้อมูลของเราได้
เช่น การส่งข้อมูลที่อาจเป็นความลับเช่นงานวิจัยทางการแพทย์หรืองานวิจัยทางด้านความมั่นคงต่างๆที่มีความสำคัญมาก การใช้เทคโนโลยีการเข้ารหัสก็เป็นหนึ่งในวิธีที่สามารถใช้ในการปกป้องข้อมูลระหว่างการส่งข้อมูลได้
ดังนั้นจะต้องให้มีมาตรฐานและการเข้ารหัสในการรับส่งข้อมูล ไม่ว่าจะอยู่ที่ไหน เพราะเริ่มจะใช้เครือข่ายอินเตอร์เน็ตกันอย่างแพร่หลายแล้ว ดังนั้นความปลอดภัยจะไม่อยู่แค่ของบุคคลใดบุคคลหนึ่ง เพราะข้อมูลทุกประการของทุกคนเหล่านั้นมีความสำคัญและควรได้รับการป้องกัน การรักษาความปลอดภัยของข้อมูลในการสื่อสารต่างๆ จึงเป็นเรื่องที่ควรให้ความสำคัญครับ
เพื่อให้การใช้งานระบบเครือข่ายอินเตอร์เน็ตให้ประโยชน์ได้เต็มที่ เพื่อที่จะแก้ไขปัญหาในเรื่องของความปลอดภัยของข้อมูลที่รับส่งกันนี้
บริษัท Netscape ได้คิดค้นโปรโตคอล SSL ขึ้นมา ซึ่งถูกนำมาแปะกับ Web Browser รุ่นแรกของตนเอง นั่นคือ Netscape Navigator SSL version 2
ในช่วงนั้น ในปี 1996 โปรโตคอล SSL ได้รับการปรับปรุงเป็น version 3.0 เพื่อที่จะให้ผู้ใช้เข้าชมเว็บไซต์ได้อย่างปลอดภัยเพิ่มขึ้น ซึ่ง SSL version 1.0 ก็มี แต่ไม่ได้นำออกมาให้ใช้งาน เราเลยไม่เห็นใน Timeline ดังรูปด้านบนเป็นการวิจัยภายใน LAB เท่านั้น
ไปถึงปี 2011 มีความพัฒนาต่อเนื่องในหลายด้าน เช่น ประสิทธิภาพของคอมพิวเตอร์, การใช้งานอินเตอร์เน็ตอย่างกว้างขวางมากขึ้น
องค์กร IETF (Internet Engineering Task Force) ประกาศให้ทราบว่ามาตรฐาน SSL 2.0 จะถูกละทิ้ง และได้ทำการเผยแพร่ RFC (Request For Comments) หมายเลข 6176 เพื่ออธิบายว่าทำไมเราต้องเลิกใช้ SSL 2.0
RFC 6176 ระบุถึงข้อเสียของ SSL 2.0 เช่น การใช้ Message Authentication แบบ MD5, ขาดการป้องกันในกระบวนการ handshake และได้กล่าวถึงการแนะนำให้ใช้โปรโตคอล TLS แทน
จากภาพ Timeline ของ SSL และ TLS ด้านบน เพื่อให้เราเข้าใจถึงความแตกต่างที่เกิดขึ้นในช่วงเวลาที่ผ่านมานะครับ
เมื่อพูดถึง SSL และ TLS บางครั้งคนอาจสับสนกันว่ามันเป็นสิ่งเดียวกันหรือไม่ คำตอบสั้นๆคือมันเกี่ยวข้องกัน แต่มันไม่ใช่อันเดียวกันครับ และความปลอดภัยของ TLS นั้นดีกว่า SSL
ถ้าเรามองที่ Timeline จะเห็นว่า TLS 1.0 ถูกสร้างขึ้นตาม RFC 2246 ในปี 1999 โดย IETF ในช่วงนั้นๆ เทคโนโลยีการเข้ารหัสที่ใช้สำหรับการสื่อสารระหว่าง 2 ฝ่าย ถูกกำหนดไว้ใน TLS 1.0 โดยมีจุดมุ่งหมายที่จะทำให้มันใช้งานได้ง่าย ขยายได้ง่าย และทำให้โปรแกรมที่ถูกพัฒนาสามารถนำ TLS ไปใช้ได้โดยไม่ต้องทำการเรียนรู้ภาษาโปรแกรมใหม่
ความสามารถของ TLS 1.0 ในการเข้ารหัสและถอดรหัส มีการใช้กำลังของ CPU สูง เพื่อใช้ในการแก้สมการทางคณิตศาสตร์ แต่ก็มีการลดจำนวนการเชื่อมต่อด้วยการใช้กระบวนการแคชชิ่ง จึงทำให้มีความรวดเร็วในการใช้งาน
นอกจากนี้ยังรองรับการเชื่อมต่อกับ SSL 3.0 ในแง่ของ backward compatibility เพื่อให้รองรับเทคโนโลยีใหม่ๆที่เข้ามา ตลอดจนถึงปัจจุบันที่ TLS ก็ได้รับการปรับปรุงไปเรื่อยๆ และมีการพัฒนาเวอร์ชั่นล่าสุดคือ TLS 1.3 ที่ออก RFC 8446 เมื่อสิงหาคม 2018 หลังจากใช้เวลาพัฒนาประมาณ 10 ปี โดยทีมงาน IETF ซึ่งได้เพิ่มความปลอดภัยและปรับปรุงความเร็วในการเชื่อมต่อ ทำให้ TLS 1.3 เป็นมาตรฐานที่นิยมใช้ในปัจจุบันครับ
ทำไมถึงต้องทำการเปลี่ยนจาก SSL ไปเป็น TLS?
SSL นั้นถูกพัฒนาขึ้นโดยบริษัท Netscape ซึ่งเป็นบริษัทเอกชนซึ่งอยู่ในความควบคุมของ AOL ในสมัยนั้น ทำให้ SSL กลายเป็นเทคโนโลยีที่ต้องเสียค่าใช้จ่าย เพราะการจะติดตั้ง web browser Netscape ต้องจ่ายเงินในการใช้งานบน Windows แม้ว่าจะเสียเงินก็ตาม แต่ความนิยมกับ Netscape ก็ยังสูงมาก โปรแกรมมีคุณภาพดี และกลายเป็นคู่แข่งให้กับ Internet Explorer ( IE ) ของ Microsoft ที่ต้องเสียเงินเช่นกันในสมัยนั้น
เมื่อเป็น Windows 98 แล้ว Microsoft ก็รู้สึกว่าต้องทำการปรับกลยุทธ์ เพื่อให้ Internet Explorer สามารถแจกจ่ายฟรีไปให้ผู้ใช้ Windows ได้ ทำให้ยอดผู้ใช้ของ Internet Explorer เพิ่มขึ้นอย่างสูง โดยมีการนำ Internet Explorer ติดตั้งมาพร้อมกับ Windows ให้ใช้ฟรีได้เลย
การที่ Microsoft ทำแบบนี้ก็ส่งผลให้ Netscape ยอดขายลดลง ทำให้มีการฟ้องร้องกัน Microsoft ถูกกล่าวหาว่าผูกขาดที่นำ IE แถมให้ฟรีมากับ Windows นั่นเอง ก็สู้คดีกับประมาณ 3 ปี จนศาลสั่งให้ Microsoft ให้ทำการแยกบริษัท เพื่อขาย OS และ Software อื่นๆ แต่ Microsoft ก็สู้คดีต่อทำการอุทธรณ์ โดยศาลสั่งให้ Microsoft ต้องลดการผูกขาดโดย Microsoft ต้องเปิด API และจบคดีผูกขาดกันไป ( รายละเอียดเนื้อหา ความเป็นมาของ Web Browser นี้ ดูได้ในคลิปนี้ https://www.youtube.com/watch?v=5oKO6e0E6IA )
ดังนั้นการเปลี่ยนจาก SSL ไปเป็น TLS ก็มีต้นกำเนิดมาจากการปรับตัวที่ต้องทำเพื่อป้องกันความผูกขาดนี้ และทำให้ TLS เป็นมาตรฐานที่นิยมใช้ในปัจจุบัน
ช่วงเปลี่ยนผ่าน SSL เป็น TLS
มีกลุ่มผู้คนหลายกลุ่มที่ต้องการเปลี่ยนจาก SSL v.2 มาเป็นโปรโตคอลใหม่ โดย Microsoft ก็เป็นหนึ่งในกลุ่มนี้ พวกเขาพยายามที่จะทำให้ SSL v.2 ให้กลายเป็นโปรโตคอลใหม่ที่ชื่อ PCT (Private Communication Technology) และนำมาใช้งานได้โดยเฉพาะใน Internet Explorer (IE) และ Internet Information Services (IIS) เท่านั้น
ส่วน Netscape ก็มีการพยายามปรับปรุง SSL v.2 ของตนให้ดีขึ้น เพื่อเตรียมพร้อมในการแข่งขันกับ Microsoft ทั้งนี้ Netscape เลยต้องรีบออกโปรโตคอล SSL v.3 ของตนเองเช่นกัน
ระหว่างการแข่งขันนี้ มีบุคคลที่มีบทบาทสำคัญ คือ Tim Dierks ซึ่งได้ชี้แจงถึงความสำคัญของการเปิดเผยโปรโตคอลตัวใหม่นี้ผ่าน IETF โดยไม่ต้องเชื่อมโยงกับบริษัทใด ๆ เขาเสนอตัวเองเป็นเจ้าภาพในการออก RFC เอง ที่จะทำให้มันเป็นมาตรฐานที่เปิดเผยและไม่เน้นจะว่ามาจากบริษัทใดก็ตาม
ต่อมา เมื่อถึงวันที่ 18 พฤศจิกายน 1996
Netscape ได้เขียนดราฟต์ของ SSL 3.0 และส่งมอบให้ IETF (Internet Engineering Task Force) เพื่อให้เป็นมาตรฐานที่ทุกคนสามารถนำไปใช้ได้ อย่างไรก็ตาม เอกสารดราฟต์นี้ยังไม่ได้รับการยืนยันเป็นมาตรฐานอย่างเป็นทางการ แต่ Draft นี้ก็อยู่ภายใต้ IETF เช่นเดิม
ผ่านไป 3 ปี เมื่อเดือนมกราคม 1999
Tim Dierks ได้เข้าร่วมทีมพัฒนาในโครงการนี้ หลังจากการตกลงกันมาจากหลายฝ่ายในช่วง 3 ปีที่ผ่านมา เขาและทีมงานได้ทำการปรับปรุงแก้ไขหลายส่วนของ SSL 3.0 และเปลี่ยนชื่อมันเป็น TLS 1.0 และได้ออกเป็นเอกสาร RFC 2246 ซึ่งเป็น RFC แรกของ TLS ที่ออกโดย IETF
Tim Dierks จึงมีบทบาทสำคัญในการพัฒนา TLS 1.0 และชื่อของเขาจะปรากฏในเอกสาร RFC ซึ่งเมื่อต้องการระบบรับส่งข้อมูลที่มีความปลอดภัยสูง ควรให้ TLS เป็นตัวเลือกหลัก โดยเฉพาะ TLS 1.3 เป็นมาตรฐานที่ได้รับการพัฒนาอย่างต่อเนื่องและลงตัวและเป็นที่ยอมรับในวงกว้างในระบบอินเทอร์เน็ต
ต่อด้วยเรื่อง Key & Cryptography
SHA-1, MD5, RC4, DES, และ 3DES คือชื่อของวิธีการเข้ารหัส (encryption) และฟังก์ชันการสร้าง Hash ที่ใช้งานใน Secure Socket Layer Protocol (SSL) ตั้งแต่เวอร์ชั่น 1.0 ขึ้นไป แต่ถูกเอาออกไปจนหมดใน TLS เวอร์ชั่น 1.3
ถ้าเมื่อเราไม่ต้องการส่งหรือแชร์ข้อมูลไปยังคนอื่น กระบวนการเข้ารหัสก็ไม่จำเป็นต้องซับซ้อนมาก
แต่ถ้าเรากำลังจะแบ่งปันหรือส่งข้อมูลให้บุคคลอื่นหลายๆคน ความยุ่งยากก็เริ่มตามมา
เพราะข้อมูลของเรานั้น แน่นอนว่ามีความสำคัญอยู่แล้ว ดังนั้น เราต้องคิดเรื่องการรักษาความลับ และความถูกต้องของข้อมูลให้เหมือนเดิมไม่ถูกเปลี่ยนแปลง ไม่ให้คนอื่นที่ไม่มีสิทธิ์เกี่ยวข้องกับข้อมูลเข้ามายุ่งกับข้อมูลเราได้ หรือ ถ้าเค้าจะพยายามยุ่ง หรือ พยายามแกะ พยายามถอดรหัสข้อมูล ก็ต้องทำให้พวกนั้นคิดว่า มันไม่คุ้มที่จะทำ คือเราต้องทำให้มันถอดรหัสยากนั่นเอง
กระบวนพวกนี้ก็สำเร็จออกมาได้ และมีใช้ใน TLS จนถึงปัจจุบัน ซึ่งจะมีวิธีการอยู่ 2 แบบ คือแบบ Symmetric ( สมมาตร) และ Asymmetric (อสมมาตร)
กระบวนการของ TLS จะมีการใช้รูปแบบคีย์เข้ารหัสทั้ง 2 แบบ คือแนวคิดก็จากตัวอย่าง ของโปรแกรม PDF Creator Free ในตอนต้นของบทความนั่นคือ รูปแบบการเข้ารหัสแบบ Symmetric ข้อดีก็คือ เร็ว ง่าย และปลอดภัย ถ้ายังไม่มีใครมีคีย์ หรือ รู้รหัสของเรา แต่ข้อเสียก็คือ ถ้าจะทำการเข้ารหัสกับไฟล์ใหม่อื่นๆอีก ก็ต้องจะสร้างรหัสใหม่ หรือเปลี่ยนรหัส ไปเรื่อยๆ เพื่อความปลอดภัย ถ้าใช้รหัสเดียวกันหมด ก็ปลอดภัยน้อยลง เช่น เราจะส่งไฟล์ 20 ไฟล์ ไปให้ทั้ง 20 คน ถ้ารหัสเดียวกันหมด 20 คนนั้น ก็เห็นข้อมูลของไฟล์คนอื่นได้หมดเพราะรหัสเดียวกัน คีย์เดียวกันนั่นเอง จะเห็นว่า เมื่อเริ่มมีการส่งไฟล์หรือส่งข้อมูลให้กัน ก็จะเริ่มจัดการเรื่องคีย์(กุญแจ)ยุ่งยากขึ้นมาแล้ว
ทางเลือกเพื่อลดความยุ่งยากก็คือ ต้องไปใช้วิธีการแบบ Asymmetric คือเราจะแจกกุญแจสำหรับถอดรหัสนั้นเพียง 1 กุญแจ ให้กับทุกคนเพื่อใช้ถอดรหัสได้นั่นเอง ซึ่งแต่เดิมเรามีกุญแจเดียว ( Symmetric สีฟ้า ) ก็เปลี่ยนมาเป็นแบบกุญแจคู่ สีแดง , สีเขียว ตามรูปด้านบน แบบ Asymmetric
ใน TLS 1.3 มีอัลกอริทึมการเข้ารหัสที่รองรับ 5 Cipher Suite ดังนี้:
TLS_AES_128_GCM_SHA256
TLS_AES_256_GCM_SHA384
TLS_CHACHA20_POLY1305_SHA256
TLS_AES_128_CCM_SHA256
TLS_AES_128_CCM_8_SHA256
สิ่งนี้แสดงให้เห็นว่ามีหลาย Cipher Suite ที่รองรับใน TLS 1.3 เพื่อให้ความยืดหยุ่นแก่เครื่องปลายทาง เพราะการส่งและรับข้อมูลนั้น ต้นทาง ปลายทาง ต้องใช้อัลกอริทึมเดียวกัน หากเครื่องปลายทางรองรับ AES256 ก็จะสามารถใช้ AES256 ได้ตามต้องการ เพราะมีหลาย Cipher Suite ที่รองรับให้เลือกใช้ได้
AES ( Advanced Encryption Standard ) เป็นมาตรฐานการเข้ารหัส (encryption) ที่ใช้ในการป้องกันข้อมูลจากการถูกเข้าถึงโดยไม่ได้รับอนุญาต ถูกพัฒนาโดย National Institute of Standards and Technology (NIST) ของสหรัฐอเมริกา และได้รับการเลือกใช้เป็นมาตรฐานการเข้ารหัสหลักในปี 2001 หลังจากที่ DES (Data Encryption Standard) ซึ่งเป็นมาตรฐานก่อนหน้านี้ถูกพบว่ามีความปลอดภัยไม่เพียงพอต่อการโจมตีในยุคปัจจุบัน จึงเป็นอัลกอรริทึ่มตัวหลักที่ถูกใช้ใน TLS 1.3
เปรียบเทียบกับ TLS 1.2 ที่มี Cipher Suite ทั้งหมด 37 แบบ ส่วน TLS 1.3 มีเพียง 5 Cipher Suite เท่านั้น ใน TLS 1.3 ได้ตัดอัลกอริทึมออกจาก TLS 1.2 ไปพอสมควร ยกตัวอย่าง เช่น
RC4 Stream Cipher,
RSA Key Exchange,
SHA-1 Hash Function,
CBC (Block) Mode Ciphers,
MD5 Algorithm,
Various non-ephemeral Diffie-Hellman groups,
EXPORT-strength ciphers,
DES,
3DES
ที่ต้องตัดออกไปก็เพื่อเพิ่มประสิทธิภาพและความปลอดภัยในการรับส่งข้อมูลมากขึ้นนั่นเอง ซึ่งถ้าเราเจอพวกนี้ในโปรแกรม Packet Capture ต่างๆเช่น Wireshark เมื่อเครื่องรับเลือกว่าจะใช้อัลกอริทึ่มไหน แสดงว่า ระบบยังไม่ได้ใช้ TLS 1.3 ก็คืออาจจะเป็น TLS 1.2/1.1/1.0 ก็คือยังใช้เวอร์ชั่นเก่าอยู่นั่นเอง
ใบรับรองดิจิตอลหรือ Digital Certificate
เป็นส่วนสำคัญของความปลอดภัยในการสื่อสารทางอินเทอร์เน็ตที่ใช้ในโปรโตคอล TLS (Transport Layer Security) หรือ SSL (Secure Sockets Layer) เพื่อให้ความมั่นใจแก่ผู้ใช้งานว่าเว็บไซต์หรือแอปพลิเคชันที่พวกเขากำลังใช้งานเป็นของหน่วยงานหรือบริษัทที่ถูกต้อง
เมื่อพูดถึงเว็บไซต์
ใบรับรองดิจิตอลจะเกี่ยวข้องกับกระบวนการ “จดโดเมน” (Domain Registration) ที่บ่งชี้ถึงผู้ครอบครองของโดเมนนั้น ๆ และใบรับรองดิจิตอลนั้นเองจะถูกออกโดยหน่วยงานที่เรียกว่า Certificate Authority (CA) ซึ่งเป็นหน่วยงานที่ทำหน้าที่ออกใบรับรองและยืนยันตัวตนของผู้ขอใบรับรอง (Certificate Applicant)
ใบรับรองดิจิตอลนี้ทำหน้าที่สร้างความเชื่อมั่นในการสื่อสาร ด้วยการใช้คีย์ข้อมูลที่ถูกเข้ารหัส และการรับรองความถูกต้องของข้อมูลจาก CA ทำให้ผู้ใช้สามารถรู้ว่าพวกเขากำลังเชื่อมต่อกับที่มาของข้อมูลที่น่าเชื่อถือ และไม่ได้ถูกแก้ไขหรือปลอมแปลงในการส่งผ่านเครือข่าย
เว็บไซต์เป็นการรับส่งข้อมูลระหว่างเครื่อง client และ web server โดยเน้นการรับส่ง 2 เครื่องกันและกัน ซึ่งทำให้การเชื่อมต่อถูกแบ่งเป็นสองฝั่ง แต่สำหรับเว็บไซต์ที่มีความสำคัญ เช่น เว็บขายของ, เว็บสถาบันการศึกษา , สถาบันการเงินการธนาคาร , หรือเว็บไซต์ของหน่วยงานราชการ เราต้องการปลอดภัยสูงสุดในการรับส่งข้อมูล โดยเฉพาะเมื่อมีการตัดเงินหรือตัดบัตรเครดิตผ่านเว็บนั้น ๆ
การจดโดเมนอย่างเดียวไม่เพียงพอในการรับรองความถูกต้องของเว็บไซต์ เนื่องจากเว็บมีความหลากหลายและเว็บปลอมสามารถทำขึ้นมาได้ง่าย การบ่งชี้โดเมนเพียงอย่างเดียวไม่สามารถตรวจสอบได้ว่าเว็บนั้นเป็นของหน่วยงานหรือบริษัทที่ถูกต้อง
เพื่อเพิ่มความมั่นใจในการสื่อสารออนไลน์ การใช้ HTTPS เข้ารหัสข้อมูลผ่าน TLS เป็นทางเลือกที่ดี เพราะมันไม่เพียงทำให้การเชื่อมต่อปลอดภัย แต่ยังมีใบรับรองดิจิตอล (Digital Certificate) ที่ออกโดย Certificate Authority (CA) เพื่อยืนยันตัวตนของเว็บไซต์ได้
การจดโดเมนไม่ได้หมายความว่าเว็บเป็นของบุคคลนั้นๆ จริงๆ เพราะโดเมนสามารถถูกนำมาปลอมแทนได้ ดังนั้น HTTPS และใบรับรองดิจิตอลเป็นเครื่องมือสำคัญที่ช่วยให้ผู้ใช้มีความมั่นใจและปลอดภัยในการสื่อสารออนไลน์ โดยเฉพาะในกรณีที่มีการทำรายการเกี่ยวกับการเงินหรือส่งข้อมูลที่สำคัญผ่านเว็บไซต์
TLS Protocol นั้นได้ถูกนำไปใช้หลากหลายเช่น ใช้กับ FTP ระบบรับส่งไฟล์ ก็คือ SFTP หรือใช้กับ SMTP ระบบส่ง Email ก็จะเป็น SMTPS
Digital Certificate หรือใบรับรองดิจิตอล
มีบทบาทสำคัญในการยืนยันความถูกต้องของ Public key ในระบบ Public Key Infrastructure (PKI) โดยเฉพาะในการใช้เทคโนโลยีเข้ารหัสแบบ อสมมาตร (Asymmetric Encryption) ที่ใช้กุญแจคู่ (public key และ private key) เพื่อความปลอดภัยของข้อมูลที่ถูกส่งระหว่างเครื่อง Client และ Web Server
Digital Certificate ทำหน้าที่ยืนยันเจ้าของ Public key และมีกลไกเพื่อระบุความเป็นเจ้าของได้ ทำให้ผู้ใช้มีความมั่นใจในการสื่อสารออนไลน์
การใช้กุญแจคู่ (Public key และ Private key) ทำให้สามารถแก้ไขข้อด้อยของการเข้ารหัสแบบสมมาตร โดย Public key สามารถแจกจ่ายได้สาธารณะ และ Private key ถูกเก็บไว้เป็นความลับ เพื่อการเข้ารหัสและถอดรหัสลับ โดยที่ไม่ต้องแจกกุญแจใหม่ทุกครั้ง
การใช้ Digital Certificate นี้เป็นส่วนสำคัญในการสร้างความปลอดภัยและความน่าเชื่อถือในโลกออนไลน์ ซึ่งเป็นสิ่งที่ทุกคนต้องการเพื่อป้องกันการปลอมแปลงและการหลอกลวงในการสื่อสารข้อมูล
ยกตัวอย่าง ผมใช้กระบวนการเข้ารหัสข้อมูล โดยการผสมข้อมูลสำคัญกับกุญแจ private key ของผมเพื่อสร้าง Cipher text แล้วจากนั้นก็ส่งให้ B
เมื่อ B ได้รับ Cipher text และใช้กุญแจ public key ของผมเพื่อถอดรหัสข้อมูล และอ่านข้อมูลที่ถูกส่งมา
กระบวนการต่อไปคือการส่งข้อมูลจาก B กลับมาให้ผม โดย B ใช้ข้อมูลของตนผสมกับ public key เพื่อเข้ารหัสลับข้อมูลและสร้าง Cipher text
จากนั้นผมได้รับ Cipher text และใช้ private key ของผมเอง เพื่อถอดรหัสลับข้อมูลและอ่านข้อมูลที่ B ส่งมา ซึ่ง B ก็จะเชื่อได้ว่า คนที่มี Private key ของผมเท่านั้น ที่จะเปิดอ่านข้อมูลได้
จะสังเกตเห็นว่า คุณสมบัติของ Asymmetric คือสามารถใช้ยืนยันตัวตนได้ เพราะว่าข้อมูลที่ได้มานั้นมาจากผมจริง เพราะใช้ Public key ถอดรหัสได้
ฉะนั้นเราต้องแยกให้ออกว่า กระบวนการยืนยันตัวตนว่าใครเป็นใคร และ กระบวนการเข้ารหัส+ถอดรหัส นั้นเป็นคนละส่วนกัน
ในโลกอินเตอร์เน็ต การสร้างตัวตนออนไลน์ ใครก็สามารถสร้างตัวตนของตนเองได้ตามต้องการ และสามารถแปลงตัวปลอมตัวเป็นบุคคลท่านอื่นหรือทำตัวเป็นบุคคลที่มีชื่อเสมือนกันก็ได้ เช่นการปลอมเว็บไซต์ต่างๆ หน้าเว็บเหมือนของจริง แต่ตัวอักษรต่างกันนิดหน่อย ก็อาจทำให้ผู้คนหลงเชื่อได้
เพราะฉะนั้นจะมีหน่วยงาน Certificate Authority (หน่วยงานออกใบรับรองดิจิตอล) เกิดขึ้นมา และกลายเป็นส่วนสำคัญในการรับรองและยืนยันตัวตนออนไลน์ เพื่อให้การรับรองว่ากุญแจ public key เป็นของบุคคลหรือหน่วยงานที่ถูกต้องเชื่อถือได้นั่นเอง ใบรับรองดิจิตอลมีบทบาทสำคัญในกระบวนการเข้ารหัสและรับรองความถูกต้องของตัวตนออนไลน์
การได้มาของใบรับรอง
1. เมื่อต้องการขอใบรับรองดิจิตอลสำหรับเว็บไซต์บริษัทของเรา เราในฐานะผู้ดูแลระบบ เราสามารถสร้างคู่กุญแจของเราเองได้ด้วยโปรแกรม puttygen ได้เลย สามารถดาวน์โหลดได้ที่นี่ สำหรับใช้งานบน Windows -> https://the.earth.li/~sgtatham/putty/latest/w64/puttygen.exe
ในกระบวนการสร้าง key pair นี้ เราสามารถใช้ puttygen หรือโปรแกรมสร้างคีย์ต่างๆ หรือ ผ่านเว็บไซต์ออนไลน์ที่ให้บริการ key pair generate ได้ เพื่อให้ได้คู่กุญแจ ( key pair ) เรามาดูตัวอย่างการสร้าง key pair ผ่านเว็บไซต์ https://www.devglan.com/online-tools/rsa-encryption-decryption เพื่อให้เห็นภาพการทำงานของ key pair ที่เป็นแบบ Asymmetric ดังนี้ครับ
เมื่อเข้าเว็บไซต์มาแล้ว ให้ทำการเลือก Key Size ตามต้องการ และกดที่ Generate RSA Key Pair ได้เลย ระบบจะสร้าง Public และ Private key มาให้เรา
จากนั้นให้เราลองทดสอบดูการทำงาน สมมติว่า เราจะให้เพื่อนของเราส่งข้อมูลมาให้เรา เพื่อนของเราก็นำ Public key จากเราไป จากนั้นก็ให้เพื่อนเราลองใส่ข้อมูล (ตัวอย่างนี้เราทดสอบบนเว็บนี้ได้เลย) ลงไปในช่อง Enter Plain Text to Encrypt จากนั้น ในช่อง Enter Public/Private key ให้เพื่อนเราใส่ Public key ที่เราสร้างไว้ก่อนหน้านี้ลงไป จากนั้นกดปุ่ม Encrypt จะเห็นว่า Output ออกมา จะอ่านไม่รู้เรื่องแล้ว ไม่มีใครอ่านข้อความนี้ได้ จากนั้น เพื่อนเราก็จะส่งข้อมูลที่เป็น Cipher text นี้มาให้เรา
เมื่อเราได้รับ Cipher text หรือ ข้อมูลเข้ารหัส ที่ส่งมาจากเพื่อนเรา เราก็จะทำการถอดรหัสด้วย Private key ที่เรามี เราก็จะอ่านข้อความนั้นได้
แต่ถ้าเราไม่มี Private key หรือใส่ Private Key ที่ไม่ถูกต้อง เราก็จะถอดรหัสข้อมูล ไม่ได้นั่นเอง คือถ้ามี Hacker จะเดาหรือสุ่ม Private key ได้นั้น ก็จะใช้เวลานานมาก หรือ อาจไม่คุ้มที่จะทำถ้า Key มีขนาดหลายบิท
2. เพื่อขอใบรับรองดิจิตอลของเรา จะต้องติดต่อ RA (Registration Authority) หรืออาจเรียกว่า CSR (Certificate Signing Request) เพื่อลงทะเบียน ซึ่ง RA มีหน้าที่ยืนยันตัวตนของผู้ร้องขอ โดยการตรวจสอบข้อมูลเช่น ต้นทางมาจากที่ไหน และเป็นใคร ซึ่ง RA ไม่มีหน้าที่ออกใบรับรอง แต่เราต้องส่งข้อมูลต่างๆให้กับ RA โดยเราต้องทำการยืนยันตัวตนด้วยข้อมูลที่ RA ต้องการ เช่น public key, เอกสารราชการ, เอกสารธุรกิจ, การยืนยันโดเมนของเว็บไซต์ว่าเราเป็นเจ้าของโดเมนจริงๆ, ที่อยู่ที่ตั้งสำนักงาน เป็นต้น เพื่อให้ RA สามารถทำการยืนยันตัวตนของเราได้จริง หลังจากนั้น หาก RA ได้รับข้อมูลการยืนยันตัวตนที่เพียงพอ RA จะส่งคำร้องไปยัง CA (Certificate Authority) เพื่อออกใบรับรองดิจิตอลให้เรา
3. เมื่อ CA ได้รับคำร้องและการชำระเงินครบถ้วน จะออกใบรับรองดิจิตอลที่มีลายเซ็นดิจิตอลครบถ้วน ระบุข้อมูลหลายฟิลด์ เช่น ผู้ออกใบรับรอง (Issuer) หมายเลข serial number, อัลกอริทึมที่ใช้, ระยะเวลาการรับรอง, และข้อมูลบุคคลหรือองค์กรที่ได้รับใบรับรอง (Subject distinguished name) ที่บ่งชี้ตัวตน ต่างๆ เช่น CN = CommonName, OU = OrganizationUnit, O = Organization, L = Locality, S = StateOrProvinceName, และ C = CountryName เป็นต้น
CA จะใช้ข้อมูลการยืนยันตัวตนและ Public key ของเรา เพื่อสร้างใบรับรองดิจิตอล โดยทั่วไปใช้มาตรฐาน X.509
เมื่อ CA สร้าง Digital Certificate แล้ว เขาจะทำ Digital Signature เพื่อให้ผู้ร้องขอเชื่อว่าใบรับรองดิจิตอลนี้มีความถูกต้องจาก CA นั้นๆ ขั้นตอนนี้เกิดจากการเข้ารหัสข้อมูลด้วยกุญแจคู่ของ CA เพื่อลงลายเซ็น จากนั้นเราจะได้รับ Cert กลับมาพร้อม Public key ของ CA ที่เราสามารถใช้ตรวจสอบได้ว่า Cert. นี้ ถูกออกโดย CA ที่เราเชื่อถือ
ทั้งนี้เป็นขั้นตอนเพียงแค่การรับรองดิจิตอลเท่านั้น ยังไม่ใช้ในเรื่องของการเอาไปใช้งานนะครับ และยังมีเรื่องอื่นๆอีกมาก เช่น Root CA, ประเภทของ SSL/TLS Certificate (เช่น OV, IV, EV) ที่มีระดับการรับรองต่างกัน ทำให้บางระดับต้องมีกระบวนการตรวจสอบทางกฎหมายที่ภายหลังต้องมีทนายความออกเอกสารรับรองทางกฏหมายแล้วปั๊ม Notary public ส่งไปให้ CA เพื่อขอใบรับรอง และยังมีเรื่องของ Chain of Trust, Revoke และอื่นๆ
การทำงานของ TLS
TLS จะทำงานบน Layer 5 กับ 6 อ้างอิงตาม OSI 7 Layers ซึ่งบางแหล่งข้อมูลก็จะบอกว่าอยู่ Layer5 และบางแหล่งข้อมูลจะบอกว่า Layer 6 ครับ โดยการทำงานของมันจะเหลื่อมๆกันทั้ง Session Layer และ Presentation Layer
TCP เป็นโปรโตคอลที่เน้นการเชื่อมต่อ (Connection Oriented Protocol) TCP จะทำการตรวจสอบความถูกต้องของ Socket โดยผ่านกระบวนการ Handshake เพื่อให้แน่ใจว่าการเชื่อมต่อเป็นไปได้ถูกต้องและได้ข้อมูลครบถ้วน ซึ่ง TLS ก็มีการยืนยันก่อนเช่นกัน กระบวนการนั้นก็คล้ายๆ กันกับ TCP ครับ
คุณสมบัติเบื้องต้นของ TCP นี้มีหน้าที่แรกคือการรับรองตัวตน (Identify) ของ Node ทั้งสองที่กำลังสื่อสารกัน โดยในขั้นตอน Handshake นี้จะระบุได้ว่า Node ต้นทางคือใคร และ Node ปลายทางคือใคร แต่การใช้เพียง TCP protocol นี้ มันไม่มีการเข้ารหัสข้อมูลครับ
ใน Application Layer เราใช้โปรโตคอล HTTP เพื่อการสื่อสาร เมื่อเราส่งข้อมูลจาก HTTP ไล่ระดับลงมายัง Transport Layer : TCP นั้นหมายถึงข้อมูลที่ส่งจากหน้าเว็บ เช่น รหัสผ่านที่ผู้ใช้กรอก เราพบว่าข้อมูลนี้ไม่ได้รับการเข้ารหัสในกระบวนการการส่งถึงปลายทางเลย
เพื่อเพิ่มความปลอดภัย เราใช้โปรโตคอล TLS ร่วมกับ TCP โดยการนำ TLS มาแปะคั่นไว้ก่อนการสื่อสารที่เกิดขึ้นในชั้น Transport Layer (TCP) นี้ เป็นการทำให้เกิดกระบวนการเข้ารหัสข้อมูลทั้งในขณะที่ข้อมูลถูกส่งไปและข้อมูลที่ถูกรับมาจาก Node ปลายทาง
แต่ถึงแม้เราจะทำการเข้ารหัสลับข้อมูลแล้ว, ก็อาจมีความเป็นไปได้ที่ผู้ไม่หวังดีอาจจะพยายามที่จะดูข้อมูลที่ถูกส่ง-รับ ซึ่งจะทำให้พวกนี้มีความยากในการถอดรหัส ไม่สามารถดูข้อมูลเราได้ง่ายๆนั่นเอง
เราจะมาทำการ Capture packet เพื่อดูว่ากระบวนการ Handshake ของ TLS นั้นเกิดอะไรขึ้นบ้าง
1. Client Hello
ผมจะทำการเข้าเว็บไซต์ www.ntplc.co.th เรามาดูกันว่า Web Browser ของผมส่งอะไรไปที่ Web Server ของ www.ntplc.co.th บ้าง โดยใช้โปรแกรม WireShark ในการดูข้อมูลใน IP Packet
จากรูป Packet capture ของโปรแกรม WireShark จะเห็นว่า Web Browser ที่ผมใช้งาน ได้ส่งข้อมูล TLS ไปหลายอย่าง ในการเปิด Client Hello ไปให้ Web Server ของ www.ntplc.co.th
เริ่มจากในส่วนของ Record Layer คือ Version TLS 1.0 ซึ่งเป็นการบอกว่า ยอมรับเวอร์ชั่นย้อนหลังได้ถึง TLS 1.0 และ ในส่วนของ Handshake Protocol ( หรือ Handshake Layer ) เป็น TLS 1.2 ซึ่งเป็นการบอกว่า Web Browser ของผมพร้อมจะตกลงใช้ TLS กับเว็บของ www.ntplc.co.th ที่ TLS 1.2 และ Web Browser ของผมมี Cipher Suites ทั้งหมด 16 Suites หรือ 16 Algorithms ที่รองรับได้ ถ้า Web Server ของ www.ntplc.co.th ได้รับข้อมูลก็เลือกเอาได้ตามนี้ และมี extension ให้ด้วย
ส่วน Field ที่อยู่ภายใต้ Handshake Protocol : Client Hello อธิบายดังนี้
Random : เป็นข้อมูล 32Byte ที่สุ่มขึ้นมา เพื่อใช้สำหรับการเข้ารหัส แล้วรับส่งกันในลำดับต่อๆไป
Session ID : เป็นหมายเลข session ที่ใช้เชื่อมต่อเข้ากับเว็บ www.ntplc.co.th เมื่อ Web Server ของ www.ntplc.co.th ได้รับเลขนี้ไป มันจะไปหาใน Cache ของ Web Server ถ้ามีก็จะ resume connection เดิม ถ้าไม่มีก็จะสร้าง session ID ขึ้นมาใหม่
Cipher Suite : คือ Algorithm ที่บอก Web Server ของ www.ntplc.co.th ว่า Web Browser ของผมเนี่ย รองรับการเข้ารหัสด้วย Algorithms ต่างๆเหล่านี้นะ ความหมายแต่ละส่วน ก็ตัวอย่างตามรูปด้านล่างนี้ ว่าใช้ในกระบวนการใด
Compression Method : เป็นกระบวนการบีบอัด ระหว่างการ รับส่ง ซึ่งช่วยประหยัด Bandwidth ได้ แต่ก็เพิ่มช่องโหว่ในเรื่องของการทำการเข้ารหัส ซึ่ง Web Browser ของผมได้ส่งไปบอก Web Server ว่า ผมไม่รองรับการบีบอัดนะ เพราะ Method ที่มีคือ null คือไม่มีการบีบอัด
2. Server Hello
เมื่อ Web Server ของ www.ntplc.co.th ได้รับ Client Hello แล้วนั้น Web Server ก็จะตอบกลับมาที่ Web Browser ของผมด้วย Server Hello
จากรูป Packet capture ของโปรแกรม WireShark จะเห็นว่า Web Server ของ www.ntplc.co.th ตอบกลับมาว่าใช้ TLS 1.2 นะ ซึ่งหมายความว่า Client ต้องใช้ TLS 1.2 หรือสูงกว่านี้เท่านั้น กล่าวคือถ้าใช้ Web Browser รุ่นๆเก่า ที่ไม่สามารถใช้งาน TLS 1.2 ได้ ก็จะไม่สามารถเข้าเว็บ www.ntplc.co.th ได้ครับ เพราะ Web Server ไม่ยอมรับนั่นเอง
ส่วน Field ที่อยู่ภายใต้ Handshake Protocol : Server Hello อธิบายดังนี้
Random : ก็ความหมายเดียวกับของ Client Hello ครับ
Session ID : เป็นเลขที่ Web Server ของ www.ntplc.co.th ส่งกลับมาที่ Web Browser ของผม จะเห็นว่าเลขไม่เหมือนกับของ Client Hello เมื่อมันทำการค้นหาใน Cache ของ Web Server แล้วไม่เจอเลขนั้น ก็เพราะว่ามันเป็นการเชื่อมต่อกันครั้งแรก มันไม่เจออยู่แล้วครับ ดังนั้นมันจะสร้าง session ID ขึ้นมาใหม่ แล้วส่งกลับให้ Web Browser ของผม เพื่อให้ใช้ session ID นี้ในการคุยกัน
Cipher Suite : จะเห็นว่า Web Server ของ www.ntplc.co.th จะเป็นผู้เลือกใช้ Algorithm ซึ่งได้เลือกการเข้ารหัสแบบ TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ดังนั้น Web Browser ของผมต้องใช้วิธีการเดียวกันนี้ด้วย โดย
TLS_ = บอกว่าเป็น TLS protocol
ECDHE_ = Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) เป็นอัลกอริทึมเพื่อใช้ในการแลกเปลี่ยนคีย์ที่ช่วยให้สองฝั่งสามารถสร้างคีย์ร่วมกันได้ในขณะที่ใช้ช่องทางการสื่อสารที่ไม่ปลอดภัยอยู่
RSA_ = Rivest-Shamir-Adleman เป็นอัลกอริทึมที่มีการใช้ในการเข้ารหัสและสร้างลายเซ็น (signature) ด้วย Public key และ Private key เพื่อการยืนยันตัวตน ระหว่าง Web Browser และ Web Server
WITH_ = เป็นการบอกว่าใช้ Asymmetric WITH_(กับ) Symmetric ด้วย
AES_256_ = Advanced Encryption Standard ที่มีความยาวของคีย์เป็น 256 bit เป็นอัลกอริทึ่มที่ใช้ในการเข้ารหัสและถอดรหัสข้อมูลในการรับส่งข้อมูลกันผ่านเครือข่าย
GCM_ = Galois/Counter Mode (GCM) เป็นโหมดการเข้ารหัส (mode of operation) ที่ใช้กับอัลกอริทึมการเข้ารหัสบล็อก เช่น Advanced Encryption Standard (AES) GCM นับเป็นโหมดการเข้ารหัสแบบ authenticated encryption with associated data (AEAD) ซึ่งหมายความว่ามันไม่เพียงแค่เข้ารหัสข้อมูล แต่ยังรวมถึงการตรวจสอบความถูกต้องของข้อมูลด้วย
SHA384_ = Secure Hash Algorithm 384-bit เป็นรูปแบบของ Message Authentication Code MAC เป็นวิธีการในการทำให้ข้อความให้ปลอดภัยจากการปลอมแปลง (tampering) หรือการเปลี่ยนแปลงโดยไม่ได้รับอนุญาต อัลกอรึทึ่มนี้จะใช้เพื่อทำการ Hash เพื่อการตรวจสอบความถูกต้องของข้อมูล
Comression Method : เป็นกระบวนการบีบอัด ระหว่างการ รับส่ง ซึ่งช่วยประหยัด Bandwidth ได้ แต่ก็เพิ่มช่องโหว่ในเรื่องของการทำการเข้ารหัส Web Server โดยทั่วไปจึงไม่ได้ใช้ฟังก์ชั่นนี้ ก็เลยเป็น null คือไม่บีบอัดครับ
3. Server Certificate , Server Key Exchange , Server Hello Done
เมื่อ Web Browser ของผมได้รับ Server Hello มาแล้ว ก็จะรอต่อไปจนกว่า Web Server จะทำการส่ง Digital Certificate มาให้ครับ
จะเห็นว่า Handshake protocol ตอนนี้จะเป็นเรื่องของการส่ง Certificate มาให้ Web Browser ครับ และใน Packet นี้ตัว Web Server ก็ส่ง Key มาให้ด้วย Handshake protocol : Server Key Exchange และส่ง Server Hello Done เพื่อบอก Web browser ว่า ทางฝั่ง Web Server ส่งข้อมูลให้หมดแล้วนะ
กล่าวคือ Web Server จะส่ง Public key มาให้ Web Browser ของผม โดยส่งมาพร้อมกับ Certificate จากรูปด้านบนจะเห็นว่า Web Server ส่ง Public key ขนาด 65 byte ทำให้ตอนนี้ Web Browser ของผมได้รับรู้แล้วว่าต้องใช้ อัลกอริทึ่มใดในการเข้ารหัส ได้รู้ว่า Web Server มี Digital Certificate อะไรที่ใช้งานอยู่ และได้รับ Public key ของ Web Server มาแล้ว เพื่อใช้ในการเข้ารหัสข้อมูลได้ต่อไป
ดังนั้นเราสามารถดูได้ที่ปลายทางที่รับ Certificate มาได้เลย ซึ่งก็คือที่ Web Browser ของเรานั่นเอง ตามรูปด้านบน
4. Clients Key Exchange , Change Cipher Spec , Encryped Handshake Message
จากนั้น Web Browser ของผมจะส่ง Public key กลับไปในขั้นตอน “ Client Key Exchange” เพื่อเริ่มการสร้าง session key ร่วมกันกับ Web Server ได้อย่างปลอดภัย โดยใช้ อัลกอริทึ่ม Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) ตามที่ Web Server แจ้งมาในขั้นตอนของ Server Hello โดย session key ของ Web Browser นี้จะทำการเข้ารหัสด้วย Public key ของ Web Server ส่งผลให้เป็น Cipher text แล้วคือ ถ้ามีคนดักข้อมูลมาอ่านก็ไม่รู้เรื่อง เมื่อ Web Server ได้รับ session key นี้ ก็ใช้ Private key ของตนเองในการถอดรหัสออกมา โดย session key นี้จะเป็น shared key คือเอาไว้ใช่ร่วมกัน ในการเข้ารหัสและถอดรหัสในการรับส่งข้อมูล
ทบทวนกันอีกที Web Server ได้ส่ง Cert กับ Public key มาให้ Web Browser ของผม โดย Web Server เก็บ Private key ของตัวเองไว้ เพื่อใช้ปลดล็อค จากรูปแบบนี้ เราจะเห็นว่าเป็นแบบ Asymmetric นั่นเอง เพราะใช้กุญแจที่ล็อค กับ ปลดล็อค คนละกุญแจกัน
จากนั้น Web Browser ของผมก็จะทำการ session key กลับไปให้ Web Server ด้วยการนำเอา Public key ของ Web Server มาเข้ารหัส session key แล้วส่งเป็น Cipher text กลับไป ฝั่ง Web Server ก็ต้องใช้ Private key ของตนเองเพื่อปลดล็อค ก็คือ ใช้กุญแจที่ล็อค กับ ปลดล็อค คนละกุญแจกัน ก็เป็นแบบ Asymmetric เช่นกัน
เมื่อจบการ Handshake ทั้ง Web Browser และ Web Server ก็จะมีกุญแจ 1 ดอก คือที่ใช้ร่วมกันคือ session key เพื่อใช้ในการเข้ารหัสและถอดรหัสข้อมูล ก็จะเป็นรูปแบบ Symmetric แต่ก่อนที่จะได้กุญแจ session key มานี้ ก็ต้องแลกกุญแจไปมาด้วยรูปแบบ Asymmetric เพื่อให้มีความปลอดภัย พูดง่ายๆคือ Web browser จะส่ง session key ไปให้ Web Server ได้เนี่ย ส่งเฉยๆธรรมดาไม่ได้ ต้องด้วยกระบวนการรูปแบบ Asymmetric ก่อนนั่นเอง มันจะได้ส่งกุญแจให้กันได้อย่างปลอดภัย คุ้มกันอย่างดี ไม่ให้มีใครขโมย session key นี้ได้ระหว่างทางนั่นเอง
คือถ้าเราใช้รูปแบบ Asymmetric ในการเข้ารหัส และ ถอดรหัส ข้อมูลที่รับส่งกันจริง มันจะช้ามาก และ CPU ทั้ง 2 ฝั่งจะทำงานหนักด้วย Web Server อาจรับการร้องขอจาก Web Browser หลายๆที่ไม่ไหว เพราะข้อมูลมีการรับส่งตลอดจากหลายๆที่
สำหรับ Change Cipher Spec ก็คือบอกให้ Web Server รู้ว่า Web Browser นั้นพร้อมแล้วสำหรับการรับส่งข้อมูลแบบเข้ารหัส ด้วย session key ตัวนี้ คือเป็นแบบ Symmetric แล้ว
ส่วน Encrypted Handshake Message เป็นการทำให้ข้อมูลในขั้นตอน Handshake นั้นปลอดภัยจากการดักจับ (eavesdropping) หลังจากที่ Change Cipher Spec ถูกส่งแล้ว, ข้อมูลใน Handshake Protocol จะถูกเข้ารหัสด้วย session key
5. Server : Change Cipher Spec , Encryped Handshake Message
เมื่อ Web Browser ตอบให้ Web Server ทราบว่า Change Cipher Spec จากนั้น Web Server ก็ตอบกลับเช่นกัน ซึ่งบาง Web Server อาจตอบ Session Ticket เพื่อระบุระยะเวลาสื่อสารด้วยเพื่อสร้าง Session Ticket ใหม่ แต่ตัวอย่าง Web Server ของ www.ntplc.co.th ไม่ได้ระบุไว้ครับ คือตอนนี้ ต่างฝ่ายต่างมี shared key คือ session key ที่เอาไว้ใช้ร่วมกันแล้ว พร้อมแล้วที่จะรับส่งข้อมูลด้วยการเข้ารหัส/ถอดรหัสแล้ว
ข้อมูลที่รับส่งหลังจากจบกระบวนการ Handshake จะเป็นข้อมูลที่อยู่ในส่วนของ Application Data ซึ่งคือข้อมูลที่เข้ารหัสแล้ว เป็น Encrypted Application Data คือ ถึงแม้ว่าจะมีคนดักจับข้อมูลไปเปิดอ่าน ก็อ่านไม่ออก ถ้าอยากอ่านออก ก็ต้องหา session Key มาให้ได้เพื่อถอดรหัสข้อมูล ก็นั่นแหละครับ ก็ต้องแฮ็คคอมของเราให้ได้ก่อน ก็อาจจะหา session key ที่อยู่ใน RAM ของเราได้ ก็ต้องย้อนถามอีกนั่นแหละ ว่ามันคุ้มที่จะทำหรือป่าว? แล้วทำได้ง่ายหรือป่าว? ก็ถือว่าปลอดภัยมากๆสำหรับ TLS protocol นี้
ที่กล่าวมานี้ เป็นตัวอย่างในการทำงานของ TLS 1.2 ซึ่ง TLS 1.3 นั้นกระบวนการ Handshake จะสั้นมากกว่านี้และปลอดภัยมากกว่าเดิม จะเห็นว่าขั้นตอน Change Cipher Spec ของ TLS 1.3 นั้นหายไป เพราะ Client Hello ส่งไปบอก Web Server เลยว่า พร้อมจะรับส่งข้อมูลแบบเข้ารหัสแล้วนะ เพราะส่ง Shared key ไปให้เลย ตามรูปด้านบนครับ
— — — — — — — — — — — — — — — — — — — — — — — — — — — — —
References :
— https://medium.com/@panupong-simto/f70892a8ac51
— https://blog.eleven-labs.com/fr/comprendre-ssl-tls-partie-1/
— https://dev.to/hegdepavankumar/ssltls-handshake-explained-a-simple-guide-for-secure-connections-2mhh
— https://blog.cloudflare.com/rfc-8446-aka-tls-1–3/
— https://blog.smithysoft.com/history-of-web-browsers/
— https://www.youtube.com/watch?v=5oKO6e0E6IA
— https://www.ramicomer.com/en/blog/differences-encryption-vs-encoding-vs-hashing-vs-obfuscation/
— https://blog.devgenius.io/added-security-measures-and-changes-in-tls-1–3-fd93bbfecb8f
— https://medium.com/@alimali.wk/http-vs-https-testing-with-kali-linux-tools-what-web-and-nikto-32f5b72477bb
— https://www.babypips.com/crypto/learn/what-is-asymmetric-encryption
— https://www.quora.com/What-is-a-digital-certificate-How-does-it-work
— https://medium.com/demystifying-security/understanding-tls-certificates-76bdd5815d95
