อธิบายเรื่อง TLS อ่านกันยาวๆ นะครับ

สวัสดีครับ

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

สุดท้ายก็เลยจะเข้ากระบวนการเดิมประจำของผม นั่นก็คือ ผมจะเขียนมันขึ้นมาเองซะเลย และครั้งนี้น่าจะเป็นการเขียนที่ยาวที่สุดด้วย อาจจะเป็นหนังสือเล็กๆ เล่มนึงเลยก็ว่าได้ ที่มาก็ไม่มีอะไร ก็แค่มาจากความสงสัยสุดจะหยั่งของผมนั่นเอง

ตัวอย่างเช่น

• ทำไมเราต้องใช้ TLS
• ทำไมเราต้องแลกเปลี่ยนคีย์
• ทำไมต้องมี root ca
• เค้าใช้ TLS กันเฉพาะเพื่อแปะบน TCP แล้วส่งไป HTTP ให้กลายเป็น HTTPS แค่นั้นกันหรือไง
• ทำไมเราต้องให้ความสำคัญกับกระบวนการเข้ารหัสลับมากขนาดนั้น

ผมจะแบ่งเป็น 3 part , part แรก คือ ที่มาที่ไปของ TLS , part ต่อมาคือ องค์ประกอบเรื่อง key และ cryptography และ part สุดท้ายคือ TLS ทำงานยังไง

— [[PART ที่ 1]] ที่มาที่ไปของ TLS —

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

เราสามารถ ป้องกันคนที่ไม่มีสิทธิ์ สามารถมาเข้ามา ปรับเปลี่ยน แก้ไขไฟล์พวกนี้ได้ ถ้าเราต้องการ

โดยวิธีการนั้นก็คือ การทำการ “เข้ารหัสลับ” (Encryption) กับไฟล์ หรือข้อมูลของเรา ซึ่งเราจะเป็นคนรู้กุญแจสำหรับ “ถอดรหัสลับ” (Decryption) แค่เพียงคนเดียว ทำให้คนอื่นไม่มีสิทธิ์เข้าถึงข้อมูลเราได้ เพราะเขาไม่รู้กุญแจ หรือเขาไม่มีกุญแจ

… ครับ ถ้าโลกนี้ง่ายแบบนี้ ก็คงไม่ใช่ หิน เหล็ก ไฟ

เพราะว่า กุญแจในการเข้ารหัสลับไฟล์ มันอาจจะเป็น

• “ข้อความรหัสผ่าน” (Passphrase)
• “กุญแจส่วนตัว” (private key)
• “โทเค่นแบบอุปกรณ์ฮาร์ดแวร์” (hardware token)
• “ลายนิ้วมือ หรือ ใบหน้าของเรา” (biometric)

หรืออะไรซักอย่าง ที่ใช้ Decryption ได้ สุดแต่จะออกแบบ

ปัญหาของเรื่องนี้คือ การเข้ารหัสลับมัน“ลืมรหัสผ่าน” , ทำหาย , รหัสผ่านรั่วไหลไปให้คนอื่นรู้ , ฯ สารพัดความเสี่ยง

ส่งผลให้ ข้อมูลอันมีค่าที่เราทำการ Encryption ไว้เริ่มมีความเสี่ยง

ว่าอาจจะมีบุคคลไม่พึงประสงค์ ได้กุญแจไปและหาทาง Decryption ข้อมูลของเราได้สักวัน………….

## ขอให้มองภาพให้ชัดว่า นี่คือการเข้ารหัสข้อมูลไฟล์ 1 ไฟล์ด้วยตัวเราคนเดียวเท่านั้น ยังไม่ได้พูดถึง การส่ง รับอะไรให้ใครใดๆ ทั้งสิ้นนะครับ (เน้น) ##

ภาพตัวอย่าง ผมกำลังทำการเข้ารหัสไฟล์ชื่อ Wallpaper2.jpg โดยใช้โปรแกรมที่ “มีความสามารถในการเข้ารหัสลับไฟล์ได้” ซึ่งโปรแกรมนั้นคือ 7zip

ตรงด้านขวา ผมจะใส่ “กุญแจ” ล็อคไฟล์ไว้ด้วยประเภทกุญแจเป็น “รหัสผ่าน” ว่า panupongkeng << อันนี้คือกุญแจสำหรับล็อค ส่วนกุญแจ จะล้ำ จะยึกยือ ไปหาช่างทำกุญแจทั่วประเทศไทยเหลากุญแจให้ตรงกันได้นั้น ก็อาจจะยาก เพราะผมเลือกใช้ “วิธีการเข้ารหัสลับ” หรือ อัลกอริทึม ในการเข้ารหัส คือ AES-256 ซึ่งแข็งมาก และยากที่คนอื่นๆ ที่ไม่รู้ จะเดาคำว่า panupongkeng ได้

เมื่อกด OK คอมพิวเตอร์จะสั่งให้โปรแกรม 7zip เข้ารหัสลับไฟล์ Wallpaper2.jpg นี้และแปลงร่างเป็นไฟล์ใหม่คือ Wallpaper2.7z ตามพารามิเตอร์ที่ผมตั้งไว้ข้างบน

ถ้าผมเก็บรักษากุญแจ คำว่า panupongkeng ไว้ดีไม่บอกใคร ก็ยากมากที่จะมีใครมาถอดรหัสลับ (Decryption) ไฟล์นี้ได้

……. แต่อย่างที่ผมบอกไปตอนแรก ปัญหามันอยู่ที่ กุญแจ นี้ มันหลุดได้ ผมก็เสี่ยงจะสูญเสียการรักษาความลับ (Confidentiality)

หรือ ผมเองดันลืมรหัสผ่านนี้ไป วันนึงผมต้องการใช้งานไฟล์ Wallpaper2.jpg ที่เข้ารหัสลับอันนี้ไว้ ผมก็ไม่สามารถใช้ได้ องค์ประกอบก็ขาดความพร้อมใช้ไป (Availability)

เพราะฉะนั้น การรักษาข้อมูลในระบบให้ปลอดภัย “ยังมีทางเลือกอีกหลายอย่าง” ยังมี Layer , Domain ต่างๆ ให้พิจารณา รวมถึงความคุ้มค่าในการเลือกใช้วิธีการและจัดเก็บกุญแจด้วย

อาจจะงง ว่าผมจะเขียนเรื่องคีย์ เรื่องเข้ารหัสพื้นฐานนี้ทำไม

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

………. ไม่มีการเข้ารหัสลับเลย ไม่ดี แย่มาก

………. เข้ารหัสลับทุกสิ่งทุกอย่างเลย ก็ไม่ดี เช่นกัน

…

เอาล่ะครับ ทีนี้เราจะย้อนกลับไปเมื่อช่วงปี ค.ศ. 1990–1995 ก็ประมาณราวๆเกือบๆ 30 ปีที่แล้ว อินเตอร์เน็ตเริ่มเกิดขึ้นมา แล้วแน่นอนมันก็ต้องมีการ “รับส่งข้อมูลผ่านคอมพิวเตอร์” กันมากขึ้นเริ่มขยับขยายแพร่หลายเป็นวงกว้าง

เราลองนึกภาพ ถ้าเรารับส่งข้อมูลกับคนอื่นๆ แต่ข้อมูลที่เรารับส่งนั้น มันไม่มีการเข้ารหัสลับเลยล่ะ ?

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

ตัวอย่างนะครับ ถ้าเราจะจีบสาวในมหาลัยอีกรัฐหนึ่ง เราส่งอีเมลไปจากเน็ตเวิร์คของมหาลัย ผ่านระบบ Routing ของเครือข่ายข้ามรัฐ ข้ามมหาวิทยาลัย แล้วเพื่อนซี้เรามันทำงานเป็นคนดูแล network อยู่ มันอยากจะอ่านข้อความจีบสาวเราในอีเมลฉบับนั้น ขอบอกได้เลยว่า เพื่อนเราทำได้นะ …. เมื่อประมาณ 30 ปีที่แล้วน่ะ

บางคนบอก แค่เมลจีบสาว ไม่เห็นต้องซีเรียสอะไรเลย ://

อันนี้ก็มาจากเรามีมุมมองด้านเดียวในชีวิตมากเกินไปครับ ในมหาวิทยาลัยมาใช้เน็ตเวิร์ค ก็มีคนตั้งหลายคน คณบดีบ้าง อาจารย์บ้าง หรือแม้แต่นักวิจัยคนอื่นๆ ซึ่งถ้ากลับกันล่ะ ดันเป็น อ.มหาวิทยาลัย จะส่งข้อมูลงานวิจัยยาอันตราย หรือวิจัยอาวุธ อะไรทำนองนี้ล่ะก็ มันอาจจะเป็นความลับที่ไม่ควรเปิดเผย “ในระหว่างทางที่ส่งข้อมูล”(in transit) ก็เป็นได้ เพราะเหตุนี้ผมถึงเกริ่นภาพชัด (contrast) ให้ทุกคนเห็นก่อนว่า เราอยู่ในจุดนึง เราจะเข้าใจและ ต้องการ(need) ว่า “การรับส่งข้อมูลระหว่างกันไม่ว่าไกลแค่ไหน ควรมีมาตรฐานกำกับ และมีการเข้ารหัสลับ เพื่อความปลอดภัย” รวมถึงคนอื่นๆ ก็น่าจะต้องการด้วย เพราะความสำคัญของข้อมุลของพวกเขานั้นแตกต่างกันแน่นอน

พูดง่ายที่สุด คือเขียนจดหมายเป็นกระดาษจีบสาว ส่งไปรษณีย์จากกรุงเทพไปเชียงใหม่ แล้วระหว่างทาง พี่ไปรษณีย์แกอ่านจดหมายเราทุกคน !!

มันจะโอเคมั้ยเล่า

ไม่ได้การแล้ว ถ้าปล่อยเป็นแบบนี้นาน เครือข่ายอินเตอร์เน็ตจะไม่สามารถใช้ประโยชน์ได้เต็มที่ ช่วงนั้นบริษัท Netscape จึงได้คิดค้นโปรโตคอล SSL ออกมา แล้วเอาเข้ามาแปะกับ Web Browser ของตัวเอง นั่นก็คือ Netscape Navigator เพื่อให้ผู้ใช้ได้เข้าชมเว็บไซต์อย่างปลอดภัย จึงเป็น SSL version 2 ในช่วงนั้น จนมาถึงปี 1996 ตัวโปรโตคอล SSL ก็ปรับปรุงมาเป็น version 3.0 ส่วน version 1 ก็มีนะ แต่มันไม่เคยถูก release ออกมาให้ใช้งาน

ต่อมาปี 2011 อะไรๆ มันก็พัฒนาขึ้นอะน้อ ทั้งประสิทธิภาพคอมพิวเตอร์ ความกระจายออกไปของอินเตอร์เน็ต หน่วยงาน IETF หรือ Internet Engineering Task Force ได้ออกมาประกาศว่า มาตรฐาน SSL 2.0 ที่เคยใช้กันมาสมัย Netscape โน่น จะต้องละทิ้งไป (abandon) จึงได้ออก RFC (Request For Comments) หมายเลข 6176 มา เพื่อบอกว่า SSL 2.0 นั้นแย่ยังไง

• ใช้ Message Authentication แบบ MD5
• กระบวนการ handshake ไม่ได้รับการป้องกันใดๆ

และข้อมูลอีกประมาณหนึ่ง รวมถึงการบ่งชี้ให้ไปใช้โปรโตคอล TLS แทน ซึ่งสามารถสื่อสารได้ ก็กดลิ้ง RFC 6176 ข้างบนไปอ่านกันเอา

https://www.liveaction.com/resources/blog/what-is-tls-1-3-explanation/

มาดูภาพ Timeline กันบ้าง เราก็จะเห็น Timeline ได้ประมาณนี้ เข้าใจง่ายดีใช่มั้ยครับ

แล้วทีนี้ก็อาจจะมีคนสงสัยว่า SSL กับ TLS มันเกี่ยวกันหรือเป็นอันเดียวกันมั้ย ?

ตอบสั้นๆ : คอนเซ็ปเดียวกัน แต่จริงๆแล้วเป็นคนละอัน และ TLS ปลอดภัยกว่า SSL

TLS 1.0 ถูกออก RFC 2246 มาตอนปี 1999 ตามรูป Timeline ด้านบน หน่วยงานที่ออกก็คือทีมงาน IETF เพราะรูปแบบการรับส่งข้อมูลเข้ารหัสแบบนี้มันเริ่มแพร่หลายเป็นสากลแล้ว การออกแบบ Standard Protocol ที่จะใช้ในวงกว้างทั่วโลกจึงต้องมี คุณลักษณะที่เป็นกลาง ใช้ได้กับทุกระบบ ทุกยี่ห้อ โดยจุดมุ่งหมายของ TLS 1.0 ได้กำหนดเอาไว้เลยว่า

• ใช้กระบวนการเข้ารหัสที่ปลอดภัย ในการสื่อสารระหว่าง 2 parties หรือ 2 peers
• สามารถทำงานร่วมกันได้ง่าย ขยายได้ง่าย กล่าวคือ โปรแกรมเมอร์จะพัฒนาโปรแกรมใดๆ ที่จะใช้การรับส่งข้อมูลแบบเข้ารหัส สามารถนำ TLS ไป adapt ใช้งานได้ในโค้ดเลย ไม่ต้องไปเรียนรู้ภาษาโค้ดใหม่ ของเครื่องปลายทางที่จะส่งให้
• มีความสามารถในการขยายได้ หรือ ใช้กุญแจเข้ารหัสถอดรหัสครั้งละเยอะๆ ได้ (bulk encryption methods)
• มีประสิทธิภาพ : เพราะการเข้ารหัสและถอดรหัสต้องใช้กำลังของ CPU สูงในการถอดแก้สมการคณิตศาสตร์เบื้องหลังจึงมีกระบวนการแคชชิ่งด้วย เพื่อลดจำนวนการเชื่อมต่อลง เอาเฉพาะที่จำเป็นเท่านั้น
• รวมถึงยังรองรับการเชื่อมต่อกับ SSL 3.0 ด้วย (backward compatibility) ซึ่งเรามักจะพบเห็นได้ทั่วไปเวลามีเทคโนโลยีใหม่ๆ เข้ามา ก็จะรองรับแบบนี้อยู่ระยะเวลาหนึ่ง

อันนี้ก็คือเป้าหมายของการออกแบบ TLS ในตอนนั้น ปี 1999 โน่น มาถึงตอนนี้ TLS ก็เป็นเวอร์ชั่น 1.3 แล้ว ออกมาตอน สิงหาคม 2018 หมายเลข RFC 8446 ทีมงาน IETF ต้องใช้เวลาร่วม 10 ปีในการพัฒนา และออก RFC ออกมา เพิ่มสิ่งที่ปลอดภัย ตัดสิ่งที่ไม่ปลอดภัย ปรับปรุงนั่นนู้นนี่ จนกลายมาเป็น TLS 1.3 ถึงทุกวันนี้

ทำไมต้องเปลี่ยนจาก SSL มาเป็น TLS ?

งั้นต้องย้อน ต้องขยี้

เราอย่าลืมว่า SSL ถูกพัฒนาโดย Netscape ซึ่งเป็นบริษัทเอกชน (ของ AOL) และตอนนั้น Netscape เป็น web browser ที่ในสมัยนั้นต้องเสียค่าใช้จ่าย หามาติดตั้งใช้งานบน Windows 1.x ถึง 4.08 ถึงอย่างนั้นแม้จะเสียเงินก็ตาม ความนิยมก็สูงอยู่ดี ตัวโปรแกรมก็มีคุณภาพ ทิ้งห่าง Internet Explorer ของ Microsoft ไปเลย พอเป็น Windows 98 Microsoft ก็รู้สึกว่า ไม่ได้ละ ต้องปรับกลยุทธ จึงทำการแจก IE ให้ใช้ฟรีๆ ติด Windows มาเลยสำหรับใครก็ตามที่ซื้อ Windows ไป ทีนี้ยอดคนใช้งาน IE ก็เพิ่มขึ้นแบบก้าวกระโดด Netscape ก็ขายไม่ได้ ยอดขายตก ทำให้ก็มีการฟ้องร้องกัน คือ อัยการมองว่า Microsoft ผูกขาดที่เอา IE เข้ามาแถมให้ฟรีๆกับ Windows อะไรทำนองนั้น ก็เป็นคดีดัง ใหญ่โต

นอกเรื่องไปไกล กลับมาช่วงเปลี่ยน SSL เป็น TLS

ต้องบอกว่ามีคนหลายกลุ่มเลยครับ ทั้ง Microsoft เองก็พยายามจะเปลี่ยน SSL 2 ให้เป็นโปรโตคอลใหม่ของตัวเองชื่อ PCT(Private Communication Technology) และจะใช้งานได้ดีใน IE และ IIS เท่านั้น ส่วน Netscape ก็ต้องการปรับ SSL 2 ของตัวเองให้ดีขึ้นเช่นกันเลยต้องพยายามรีบเข็น SSL 3.0 ออกมาโดยไว ต่างคนต่างแข่ง

ระหว่างการแข่งนี้ ก็มีคนมองเรื่องพวกนี้ออก นั่นคือ Tim Dierks (ค้นกันเอาเองได้ว่าเขาคือใคร) ได้หาโอกาสประชุมพูดคุยกับทุกฝ่ายทั้ง Netscape และ Microsoft หรือดีล ตกลงกันนั่นแหละ เพราะ Tim เขาก็รู้จักคุ้นเคยกันกับทั้งหลายๆฝ่าย ว่าต่อไปนี้การออกมาตรฐานโปรโตคอลตัวใหม่นี้ ให้เปิดเผย โดยออกผ่าน IETF ไม่อยากให้เป็นตรายางประทับว่าออกมาจากบริษัทใดบริษัทหนึ่ง โดยเขาจะเป็นคนเจ้าภาพในการออก RFC เอง ….. ก็มาลองลุ้นกันนะครับว่าเขาจะได้เป็นเจ้าภาพจริงมั้ย

18 พฤศจิกายน 1996 จนแล้วจนรอด ทาง Netscape ก็สามารถเข็นดราฟต์ SSL 3.0 ออกมาให้ IETF จนได้ แต่เอกสาร Draft ก็คือยังไม่ใช่ของจริงหรือไฟน่อลล่าสุด (ก็ draft มันก็คือ draft ไง) และ Draft นี้ได้อยู่ภายใต้ IETF นั่นแหละครับ

ทีนี้พอผ่านไป 3 ปี กลายเป็น มกราคม 1999 Tim ได้อยู่ในทีมพัฒนานี้ด้วย , หลังจากที่เขาอยู่ในการตกลงหลายฝ่ายย่อหน้าก่อนหน้าที่ผมเขียนนั้น , ช่วง 3 ปีผ่านไปเขาและทีมงานได้ทำการเอา SSL 3.0 มาปรับปรุงแก้ไขอีกครั้งหลายส่วน และเปลี่ยนชื่อจาก SSL 3.0 มาเป็น TLS 1.0 ได้เลข RFC 2246 ซึ่งเป็น RFC แรกของ TLS ที่ออกโดย IETF นั่นเอง เราก็จะเห็นชื่อของ Tim อยู่ที่เอกสาร RFC ครับ อันที่จริง จะดูเหมือน IETF ลอกเอา SSL 3.0 ของ Netscape มาปั๊มตรา ใหม่เป็น TLS แล้วบอกว่า เฮ้ย นี่ออกโดย IETF นะเว้ย อย่างนั้นใช่มั้ยครับ ? คำตอบคือทั้งใช่และไม่ใช่แหละครับ (Tim บอกเมื่อปี 2014 ว่าพอมองย้อนกลับไปเรื่องพวกนี้งี่เง่านะ)

ก็นั่นแหละ เคลียร์ชัดเลยนะครับว่า SSL ถูกแทนที่ด้วย TLS จริง

TLS แข็งแรงกว่า SSL

กระบวนการรับส่งข้อมูลระหว่างเครื่องต่อเครื่อง ที่จะรับส่งอย่างปลอดภัยที่สุด ต้องใช้ TLS เท่านั้น และควรเป็น version 1.3 ด้วย ซึ่งถูกขัดเกลาแก้ไขมาถึง 28 Drafts เป็นเวลาหลายปีเลยทีเดียว

จบ PART ที่ 1

— [[PART ที่ 2]] องค์ประกอบเรื่อง key และ cryptography—

SHA-1, MD5, RC4, DES, and 3DES. พวกเรารู้มั้ยครับ ว่าชื่อพวกนี้คืออะไร

ผมจะเขียนให้อ่านสำหรับคนที่พื้นฐานไม่มากว่า “มันคือองค์ประกอบ ของ Secure Socket Layer Protocol (SSL) ที่ฝังอยู่ใน TLS เวอร์ชั่น 1.0 เป็นต้นมา และถูกเอาออกไปจนไม่เหลือแล้วใน TLS 1.3

เพราะฉะนั้น ถ้าใน part นี้ ผมจะเขียนเรื่อง key และ cryptography เฉพาะของ TLS 1.2 กับ 1.3 เท่านั้นครับสาเหตุเพราะ 1.2 ยังมีใช้อยู่ในวงกว้าง ณ ปัจจุบัน (ตุลาคม 2022) ยังถือว่ากว้างอยู่ในระดับหนึ่ง ส่วน 1.3 คือดีมากกว่าเดิม แต่ก็เปลี่ยนโฉมไปเยอะเช่นกัน

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

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

กระบวนการเข้ารหัสที่จะทำให้เรื่องพวกนี้สำเร็จได้ จึงถูกนำมาใช้ใน TLS จนถึง Timeline ปัจจุบันก็พัฒนาจาก 1.0 จนถึง 1.3 แล้ว ด้วยวิธีการ 2 แบบ คือ แบบ สมมาตร (symmetric) และ อสมมาตร (asymmetric)

กระบวนการของ TLS ใช้รูปแบบคีย์เข้ารหัส ทั้งสองแบบครับ….

ทำไม TLS ต้องใช้ทั้ง symmetric และ asymmetric ละครับ ?

เราจะพูดเรื่องคอนเซป หรือแนวคิดกันก่อนครับ เห็นตัวอย่าง 7zip ข้างบนทีผมเขียนไปมั้ยครับ นั่นคือรูปแบบการเข้ารหัส แบบ symmetric ครับ มันมีข้อดีคือ เร็ว ง่าย ปลอดภัย (ถ้ายังไม่มีใครรู้กุญแจ นอกจากผมอะนะ มันก็ยังปลอดภัยอยู่) แต่มันก็มีข้อเสียคือ ถ้าผมจะเข้ารหัสไฟล์อื่นๆ ข้อมูลอื่นๆ ผมควรจะเปลี่ยนคีย์ใหม่ เพื่อความปลอดภัย Different key for different parties นั่นเอง หรือข้อมูลผม 10 ชุด ส่งให้คน 10 คน ผมก็ไม่ควรใช้กุญแจซ้ำกันครับ ไม่งั้นพออีกคนทำกุญแจหลุด คน 10 คนนี้ก็อาจจะหาทางเข้าถึงข้อมูลของคนอื่นได้ถ้าผมใช้คีย์ซ้ำกัน

เห็นมั้ยครับว่า เราไม่ได้เก็บข้อมูลไว้คนเดียวอีกต่อไปแล้ว เราต้องมีการรับข้อมูลจากคนอื่น และเราต้องส่งไปให้คนอื่นด้วย การบริหารจัดการกุญแจ มันเลยยุ่งยากขึ้นมา

มันมีทางมั้ยนะ ที่ผมจะแจกกุญแจสำหรับถอดรหัสแค่ 1 กุญแจ ให้กับทุกคน แล้วทุกๆคน สามารถเอากุญแจของผมนี้ ไปถอดรหัสได้ ?

คำตอบก็คือ มีวิธีการอีกแบบนึงนั่นคือการเข้ารหัสแบบ อสมมาตร หรือ asymmetric encryption โดยแต่เดิม เรามีกุญแจเดียว (สีฟ้า-symmetric) ก็เปลี่ยนเป็นกุญแจคู่ key pair , สีแดง กับ สีเขียว)

Encryption | TRICKSTER (computer-trickster.blogspot.com)

รูปแบบการ encryption ทั้งสองแบบ ต่างมีข้อดีข้อเสีย มาเสริมส่วนที่ขาดซึ่งกันและกันครับ คอนเซปเอาแบบนี้ก่อน เพราะเนื้อหาตรงนี้เว็บไทยเขียนไว้เยอะ และเขียนไว้ดีด้วยครับ ไปค้นต่อกันได้

สรุปสั้นๆ ตรงนี้ก่อนว่า TLS ใช้ทั้ง 2 แบบ

ทีนี้มาเจาะลึกในแต่ละแบบที่อยู่ภายใน TLS ตามชื่อ part ที่ผมระบุไว้

TLS 1.3 มีอัลกอริทึมการเข้ารหัสที่รองรับ 5 Cipher Suit ดังนี้

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

เราจะเห็นว่า

• มันมีหลายอันที่รองรับ เพราะการออกแบบคือต้องให้เครื่องปลายทางส่วนใหญ่ ใช้งาน ถอดรหัสได้ด้วย คืออัลกอริทึมที่เครื่องรับและเครื่องส่งใช้อันเดียวกัน จะใช้ AES256 ก็ได้ถ้าอีกฝั่งรองรับอะนะ เพราะงั้นมันเลยมีหลายๆอันไง
• AES ได้รับความนิยมเนาะ ยังอยู่กันเต็ม TLS1.3 ไปหมด แสดงว่ามันแข็งแรงจริง

TLS 1.2 มี 37 Cipher suit

TLS 1.3 มี 5 Cipher suit

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

ถ้าเราเจอข้อมูลพวกนี้ใน Wireshark หลังจากที่เครื่องรับตอบตกลงว่าจะใช้เลือกใช้อัลกอริทึมไหน แสดงว่า ยังไม่ใช่ TLS 1.3 ก็คือเป็น TLS 1.2 / 1.1 / 1.0 ทำนองนั้น ก็เก่ากว่านั่นเอง

ตรงนี้ผมจะขอหยุดค้างในรายละเอียดทางเทคนิคไว้ก่อนครับ แล้วผมจะย้อนกลับมาใหม่ เอาเป็นว่า มันมีการตัดออกเยอะ จาก 1.2 แล้วแปลงร่างเป็น TLS 1.3 ซึ่งประสิทธิภาพดีกว่าเดิมมากโดยยังปลอดภัยสูงอยู่มากเช่นกัน

ผมจะเข้าสู่องค์ประกอบหนึ่งของการเข้ารหัส ที่สำคัญมากอีกอันนึง นั่นคือ ใบรับรองดิจิตอล (Digital Certificate) มาดูกันครับว่าเกี่ยวกับเรื่อง Key Cryptography ของ TLS ยังไง

เรามักจะยกตัวอย่างจาก “เว็บไซต์” ซะเป็นส่วนมากนะครับ เพราะว่า เว็บไซต์จำนวนมาก บ่งชี้ถึงว่า เป็นเว็บของหน่วยงานอะไร บริษัทอะไร สถาบันอะไร แต่ข้อมูลคอมพิวเตอร์มันสามารถทำซ้ำกันได้ง่าย เหมือนเรา Copy แล้ว paste หรือลอกเว็บไวต์มาทั้งดุ้น ก็ทำได้

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

โอเค เมื่อเกิดระบบการจดโดเมนเกิดขึ้น เลยเกิดเว็บไซต์มากมายหลายร้อยล้านเว็บไซต์ คงไม่ต้องบรรยายตรงนี้มาก

แต่รู้มั้ยครับ เว็บไซต์เนี่ยมันคือ การรับส่งข้อมูลระหว่างเครื่อง client และ web server ซึ่งเป็นการรับส่ง 2 เครื่อง กันและกันแล้วล่ะ เพราะฉะนั้น ถ้าเว็บไซต์เหล่านั้น

• เป็นเว็บขายของออนไลน์ มีการตัดเงิน ตัดบัตรเครดิต
• เป็นเว็บไซต์สถาบันการศึกษา มีการลงทะเบียนออนไลน์
• เป็นเว็บไซต์หน่วยงานราชการ

เราจะไม่สนใจการส่งข้อมูลแบบเข้ารหัสให้ปลอดภัย บ้างเชียวหรือ ?

ก็อาจจะมีคนตอบว่า “จดโดเมนไว้แล้วไง นี่แหละก็บ่งชี้ได้แล้วว่าเป็นเว็บธนาคารจริง”

คำตอบคือ แค่จดโดเมน ยังไม่สามารถบอกได้ว่าเว็บนี้เป็นของหน่วยงานนี้จริง เพราะเว็บมันปลอมกันได้ โคลนกันได้ facebook.com ปลอมก็อาจจะเป็น focebaok.com ก็ได้ อย่าคิดว่าตัวเรามองออก รู้ ว่าเป็นคนละเว็บกัน เพราะจริงๆ มีคนอีกเรือนหมื่น ที่เขาไม่รู้จริงๆ มองไม่ออกและตกเป็นเหยื่อเว็บปลอม

อีกซักตัวอย่างละกันครับ เช่น พี่ข้างบ้านผมเปิดร้าน พี่ดาวส้มตำ วันๆ แกก็ทำแต่ส้มตำไม่ได้ทำอย่างอื่น ผมนึกสนุกอยากปลอมเป็นแกในโลกออนไลน์

ผมก็ไปจดโดเมน pdaosomtum.com ได้เลย

วันนึงแกอยากเปิดร้านออนไลน์ แกชอบโดเมนชื่อนี้แกก็หมดสิทธิ์จะจดแล้ว ต้องซื้อต่อจากผม หรือไม่ก็ รอผมปล่อยโดเมนหมดอายุ ค่อยจดเองใหม่ หรือไปจดโดเมนชื่ออื่นๆ เช่น pdaosomtumzap.com เป็นต้น

การจดโดเมน เป็นการจดเพื่อนำชื่อไปใช้ให้คนได้จดจำได้ง่าย หรือสะดวกในการเขียนโปรแกรมเชื่อมต่อ ไม่ได้แปลว่า จดโดเมนชื่อนี้ แล้วเนื้อหาในเว็บไซต์ จะเป็นแบบที่จดโดเมนเสมอไป ชื่อโดเมนแบบนึง แต่เนื้อหาข้างในอาจจะอีกแบบนึงก็ได้

เพราะฉะนั้น จะต้องมีกลไกบางอย่าง เพื่อรับรองว่า สถานที่นี่ ปลายทางนี้ เว็บนี้ เป็นของ “คนๆ นี้ , นิติบุคคล นี้ , ห้างร้าน , บริษัทนี้ , หน่วยงานราชการนี้ ฯ จริง ๆ “ เพื่อเป็นประโยชน์ต่อเจ้าของเว็บ และผู้เยี่ยมชมเว็บ

บางคน ทั้งผู้รับและผู้ส่ง ต้องการให้ปลอดภัยสูงสุด เพราะเว็บมีการตัดบัตรชำระเงินในเว็บ เว็บไม่อยากเสียลูกค้าไปอยากให้ลูกค้าเชื่อมั่น ลูกค้าก็ไม่อยากโดนเว็บปลอมหลอก

บางคน ทั้งผู้รับผู้ส่ง ไม่ต้องการยุ่งยาก เพราะเป็นเว็บเขียนกลอน เจ้าของเว็บเขียนกลอนไว้เล่นๆ เขียนมุกจีบสาว คนเข้าชมก็ไม่ได้ซีเรียส ว่าต้องยืนยันบุคคลอะไรขนาดนั้น อ่านกลอน อ่านมุกสนุก ก็พอแล้ว

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

HTTP vs HTTPS Security: The Differences Between These Protocols (cheapsslsecurity.com)

จริงๆแล้ว โปรโตคอล TLS ถูกนำไปใช้ได้มากกว่านี้นะครับ

เช่น

เอาไปใช้กับ FTP ก็จะกลายเป็น SFTP

เอาไปใช้กับ SMTP ก็จะกลายเป็น SMTPS

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

เมื่อจะมาใช้ HTTP แบบเข้ารหัสให้ปลอดภัย ก็หนีไม่พ้นเรื่อง ขั้นตอนการเข้ารหัส และขั้นตอนการถอดรหัส โดยใช้กุญแจ(key) ในการรับส่งข้อมูลระหว่างกัน

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

หน่วยงานนั้นมีชื่อว่า Certificate Authority

หมายถึง ผู้ออกใบรับรองดิจิตอล หรือ หน่วยงานออกใบรับรองดิจิตอล ซึ่งในโลกนี้ก็มีหลายเจ้าที่ให้บริการ เช่น Identrust , Digicert , Sectigo , Let’s Encrypt ฯ อีกหลายเจ้า มีทั้งแบบ ออกใบรับรองดิจิตอลให้ฟรี และแบบเสียเงิน

Digital Certificate ที่เราจะได้มา มันเอามาเพื่ออะไร ?

คำตอบคือ : เพื่อใช้ยืนยันว่า ใครเป็นเจ้าของ public key ซึ่งถ้าเราหมุนเมาส์ไปด้านบนของบทความ เราจะเห็นกุญแจสีเขียว( public key) และกุญแจสีแดง (private key) อยู่ในภาพตัวอย่าง เป็นการเข้ารหัสลับแบบ อสมมาตร , Digital Certificate นี้ก็เลยทำหน้าที่นี้ คือ ยืนยันเจ้าของ public key เมื่อยืนยัน public key ได้ ใบรับรองดิจิตอลก็จะมีกลไกบ่งชี้ยืนยันความเป็นเจ้าของได้ ว่าเป็นของใคร เพราะคนที่เป็นเจ้าของตัวจริงจะรักษากุญแจคู่ของเขา ซึ่งก็คือ private key ไว้อย่างดี ภาพใหญ่ของเรื่องนี้ถ้าเราไปค้นต่อ มันก็คือ PKI หรือย่อมาจาก Public Key Infrastructure

ทำไมต้องมีกุญแจคู่ (public key , private key) ?

คำตอบคือ : ถ้าเรามองความแตกต่างของการเข้ารหัสแบบ สมมาตร และ อสมมาตร ออก เราจะพบข้อดีข้อเสีย ของทั้งสองแบบ การเกิดขึ้นมาของระบบกุญแจคู่ ที่ใช้สำหรับรูปแบบอสมมาตร จะมาแก้ไขจุดด้อยของสมมาตร เพราะการเข้ารหัสลับ และถอดรหัสลับ ของประเภทนี้ ใช้กุญแจไม่เปลือง ไม่ต้องแจกกุญแจใหม่ ทุกๆคน ให้ไม่ซ้ำกันให้กับคนพันๆ หมื่นๆ แสนๆ คน ตรงนี้อสมมาตรทำได้ครับ โดยการแจกกุญแจ สาธารณะ (public key) ซึ่งคุณสมบัติ ก็ตามชื่อของมันนะครับ คือ ใครจะเอาไปก็ได้ เพราะมันเป็นกุญแจ สาธารณะ ………… ขั้นตอนอาจจะงงๆ นิดหน่อย แต่ขอเล่าแบบสั้นๆแล้วกันครับ

เจ้าของข้อมูล ผม ภานุพงษ์ เข้ารหัสลับข้อมูล โดยเอาข้อมูลสำคัญ ผสมกับกุญแจ private key ของผม (นึกภามตามช้าๆนะครับ)

ข้อมูลนั้นก็จะถูกเข้ารหัสกลายเป็น Cipher text ผมส่งข้อมูล cipher text ให้ สมหญิง

สมหญิง ได้รับ cipher text ต้องการอ่านข้อมูลจึงทำการถอดรหัสลับด้วยการใช้กุญแจ public key ของผม

กุญแจคู่ public key ที่สมหญิงมี + cipher text ที่สร้างมาจาก private key ที่ผมเป็นคนเข้ารหัสลับ (encryption) = สมหญิงจึงถอดรหัสลับ(decryption) และอ่านข้อมูลได้

กลับกัน ขากลับ สมหญิง ต้องการจะส่งข้อมูลกลับมาให้ผม

สมหญิง ต้องเอาข้อมูลของเธอ ผสมเข้ากับ public key กลายเป็นการเข้ารหัสลับข้อมูล ได้มาเป็น cipher text เช่นเดียวกัน

สมหญิงส่งข้อมูลกลับมาให้ผม ผมได้รับ cipher text

ผมต้องการเปิดอ่าน ผมก็ใช้ private key ตัวเอง ถอดรหัสลับและเปิดอ่านข้อมูล ผมก็จะได้รับข้อมูลที่อ่านได้

เราต้องแยกให้ออกนะครับว่า

### กระบวนการยืนยันตัวตนว่าใครเป็นใคร หรือ ใครเป็นคนนั้น จริงๆไหม

กับ

กระบวนการเข้ารหัส+ถอดรหัส เป็นกระบวนการคนละส่วนกัน ###

.

จะสังเกตว่า

• จังหวะที่ผมส่งข้อมูลให้สมหญิง > สมหญิงจะได้รับการยืนยันว่าข้อมูล มาจากผม ภานุพงษ์ เพราะเอากุญแจสาธารณะ (public key) ของผมมาถอดรหัสลับได้
• จังหวะที่สมหญิงส่งข้อมูลมาให้ผม > สมหญิงจะเชื่อได้ว่า คนที่มีกุญแจส่วนตัว (private key) ของภานุพงษ์ เท่านั้นที่จะเปิดอ่านข้อมูลได้

เพราะฉะนั้นแล้วคุณสมบัติของการเข้ารหัสแบบ อสมมาตร ที่แตกต่างจาก สมมาตร อันหนึ่งก็คือ > สามารถยืนยันตัวตนได้ (authentication)

ทีนี้เนี้ยในโลกอินเตอร์เนต เอาจริงๆแล้วก็นั่งพิมพ์ๆ นั่งเขียนเว็บ นั่งเขียน blog หรือโพสต์โซเชียลเล่นๆได้ว่า “ใครอยากจะเป็นใคร” ก็ได้ครับ ผมอยากจะเป็น บิล เกตส์ ยังได้เลย ดังนั้น ผมก็บอกว่า ผมชื่อ บิลเกตส์ นะ ผมมีเว็บไซต์ส่วนตัวคือ billgatesuperfastz.com ผมก็ประกาศออกไปว่าผมเป็นบิล เกตส์ จริงๆ

คนไอทีก็คงขำ เพราะคิดว่า ใครมันจะไปเชื่อ…………….

แต่……………มันก็มีคนไม่รู้ และอาจจะเชื่อ ก็ได้

อย่าประเมินความสุดจะหยั่งของมนุษย์ครับ

เพราะฉะนั้น หน่วยงานออกใบรับรองดิจิตอล หรือ Certificate Authority จึงเกิดขึ้นมา และขอพิมพ์อีกครั้ง ว่า ใบรับรองดิจิตอล ที่เรากำลังพูดถึงอยู่นี้ ออกมาเพื่อรับรองว่า กุญแจ public key นี้เป็นของใคร

ใบรับรองดิจิตอลเป็นส่วนจำเป็นในการเข้ารหัส แต่ผมจะยังไม่อธิบายในพารากราฟนี้

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

1. หากเรามีเว็บไซต์บริษัท และต้องการขอใบรับรองดิจิตอล สมมติเราเป็นผู้ดูแลระบบเว็บไซต์ หรือโครงสร้าง IT ต่างๆ เราสามารถสร้างคู่กุญแจของเราเองได้เลย (public key / private key) ใช้โปรแกรม Gpupg หรือ puttygen ก็ได้ และใส่ parameter ที่จะเป็นให้ครบ ตัวอย่างการสร้าง key ขึ้นมาโดยใช้ puttygen ซึ่งถ้าเราเลือกเมนู Key > Generate key pair เราก็จะสร้างได้ หลังจากสร้างเสร็จเราก็ save เก็บไว้ได้ทั้ง private key และ public key โดย private key เราจะต้องเก็บไว้ให้ดีๆ เพราะมันเป็นกุญแจที่ใช้ถอดรหัสข้อมูลทุกข้อมูล ที่เข้ารหัสจาก public key คู่ของมัน (นึกภาพตาม ช้าๆ ให้ออก ให้ได้นะครับ)

2. จะต้องติดต่อ RA (Registration Authority) หรือบางแห่งก็จะเรียกว่า CSR (Certificate Signing Request) เพื่อลงทะเบียน โดย RA จะมีหน้าที่ยืนยันตัวตนของผู้ร้องขอ ว่าเป็นใครมาจากไหนอะไรยังไง RA ไม่ได้มีหน้าที่ออกใบรับรองให้นะครับ ซึ่งเราอาจจะต้องส่งมอบข้อมูลอะไรบางอย่างให้กับ RA เช่น public key ของเรา เอกสารราชการ , เอกสารธุรกิจ , การ verify โดเมนของเว็บไซต์ ว่าเราสามารถยืนยันได้หรือไม่ว่าเป็นเจ้าของโดเมนจริงๆ , ที่อยู่ ที่ตั้งสำนักงาน ต่างๆ ฯ เพื่อยืนยันตัวตนจริงๆ หลังจากนั้น หาก RA ได้รับข้อมูลการยืนยันตัวตนที่มากเพียงพอแล้ว ก็จะส่งคำร้องไปยัง CA หรือ Certificate Authority เพื่อออกใบรับรองดิจิตอลให้เรา ต่อไป

3. CA เมื่อได้รับคำร้องที่ครบถ้วนแล้ว รวมถึงอาจจะได้รับการจ่ายเงินจากเราแล้ว ก็จะสร้างใบรับรองดิจิตอลโดยมีการลงลายเซ็น (Digital Signature) มาให้ครบถ้วน เช่น ใบรับรองนี้ออกโดยใคร (Issuer) , มีหมายเลข serial number อะไร (เพราะมันต้องไม่ซ้ำกัน) , ใช้อัลกอริทึมอะไรในการลงลายเซ็น , ระยะเวลาการรับรองว่านานเท่าไหร่ , Subject distinguished name ก็คือออกใบรับรองให้ใคร และอีกหลายๆฟิลด์ข้อมูล ที่บ่งชี้ตัวตน (CN = CommonName , OU = OrganizationUnit , O = Organization , L = Locality , S = StateOrProvinceName , C = CountryName) เป็นต้น

งานของ CA เขาก็จะใช้ข้อมูลการยืนยันตัวตนของเราร่วมกับ public key ของเรา ที่ได้รับ มาสร้างใบรับรองดิจิตอลให้ โดยทั่วไปจะใช้มาตรฐาน X.509 ออกมา

Basics of Digital Certificates and Certificate Authority — Web Service Security Tutorial (google.com)

ตอนที่ CA สร้าง Digital Certificate เนี่ยผมได้บอกไปแล้วข้างบนว่าเขาทำการลงลายเซ็นดิจิตอลด้วย เพราะจะทำให้ผม (ผู้ร้องขอใบรับรอง) เชื่อได้ว่า ใบรับรองดิจิตอลนี้ ออกโดย เขา (ก็คือ CA เจ้านี้) จริงๆ และขั้นตอนการทำ Digital Signature ก็มาจาก การเข้ารหัสของกุญแจคู่ของ CA นั่นเอง โดยในกล่องสุดท้ายขวามือเราจะเห็นว่า เขาจะส่งใบรับรองดิจิตอล (Cert) กลับมาให้เรา พร้อมกับ public key ของเขา

เราจึงสามารถตรวจได้ว่า ใบรับรองนี้ ออกโดย CA นี้จริงๆ นั่นเองครับ

แต่เราจะเอาไปใช้ยังไง อีกเรื่องนึงนะครับ อันนี้แค่ขั้นตอน การรับรองทางดิจิตอล เท่านั้น ซึ่งมันยังมีอีกมาก เช่น มี Root CA , มีเรื่อง Type ของ SSL/TLS Certificate ว่าเป็นประเภทไหน เช่น OV , IV , EV ต่างๆ ซึ่งระดับการรับรองก็ต่างกัน บางระดับ ต้องให้ทนายความออกเอกสารรับรองทางกฎหมายแล้วปั๊ม Notary public ส่งไปให้ CA เพื่อขอใบรับรองเลย , มีเรื่อง Chain of Trust , มีเรื่อง Revoke ฯ อีกมากมาย

เอาล่ะ มันก็ยาวมาระดับนึง คราวนี้เราขอรวบรัดตัดตอน และก็ถือว่า เราได้ใบรับรองดิจิตอลมาแล้ว และมาจากหน่วยงาน หรือขั้นตอนที่น่าเชื่อถือด้วย

ต่อไป เราจะเอา Digital Certificate มาใช้งานใน TLS ยังไง มาดูกันต่อครับ

— [[PART ที่ 3]] การทำงานของ TLS —

TLS ทำงานบน Layer 5 กับ 6 แบบขี่ๆ กัน แปะอยู่เหลื่อมๆ กัน ใน Presentation Layer ของ OSI 7 Layers Reference Model ซึ่งผมได้เขียนไปในหลายบทความของผมเสมอว่าพื้นฐาน OSI 7 Layers นั้นสำคัญมากๆ ครับ

OSI Model | Computer Networking | CompTIA

TCP เป็น Connection Oriented Protocol จุดมุ่งหมายหลักของ TCP ก็คือ จะยืนยันว่า ต้นทางปลายทางรับส่งกันได้จริง ใน Socket ที่ถูกต้อง ก็จะทำการตรวจสอบ (Handshake) ให้ครบถ้วน เมื่อครบแล้วยืนยันแล้วก็จะเริ่มรับส่งข้อมูลตาม Socket , คุณสมบัตินี้แหละ เป็นคุณสมบัติเบื้องต้น ที่จะใช้ Identify ระหว่าง 2 Node ที่สื่อสารกันได้ ว่า ต้นทางคือใคร ปลายทางคือใคร

………แต่การส่งข้อมูลแบบนี้มันไม่เข้ารหัสลับ ครับ

ถ้าเราเห็นจากภาพตารางสีฟ้าด้านบน application layer เรามีโปรโตคอล HTTP ใช้ แล้วส่งต่อมาให้ TCP นั่นแปลว่า หน้าเว็บ รหัสผ่านที่กรอกในเว็บ ต่างๆ มันไม่มีการเข้ารหัสลับเลย เราเลยเอา TLS เข้ามาแปะคั่นไว้ก่อน TCP เพื่อจะได้มีกระบวนการเข้ารหัสลับในการรับและส่งข้อมูลกับอีก Node อย่างปลอดภัย เมื่อเข้ารหัสลับแล้วส่งข้อมูลออกไป ระหว่างทางอาจจะมี “ผู้ไม่หวังดี หรือ รัฐบาลบางประเทศ อยากจะแกะดูข้อมูลการรับส่ง” เขาก็จะทำได ้, เขาก็อาจจะพยายามทำ , เขาก็ทำแล้วแต่ยังแกะไม่ออก ฯลฯ แล้วแต่ว่าชีวิตพวกคุณไปเจอกับอะไร ถ้าจีน หรือรัสเซีย หรือคาซัคสถาน ก็แย่หน่อย ถ้าฟินแลนด์ นิวซีแลนด์ ก็ดีหน่อย ประมาณนั้น ก็ เกิดให้ถูกประเทศนะครับ

และผมขอย้ำอีกครั้ง

### กระบวนการยืนยันตัวตน กับ กระบวนการเข้ารหัส+ถอดรหัส เป็นกระบวนการคนละส่วนกัน ###

ส่วนเรื่อง TCP ผมเขียนไว้แล้ว เข้าไปอ่านกันได้ครับ << คลิก

OK มาเรื่อง TLS กันต่อ

TLS ก็มีการยืนยันก่อนเช่นกัน กระบวนการนั้นก็คล้ายๆ กันกับ TCP ครับ

STEP ที่ 1 : Client Hello ผมจะใช้คอมผมเข้าเว็บไซต์ tls-v1–2.badssl.com มาดูกันว่าคอมผมส่งอะไรไปบอกเว็บนี้บ้าง , Wireshark โลด

จะเห็นว่าคอมผมส่งข้อมูล TLS ไปหลายอย่างมากมาย ในการเปิด Client Hello กับเว็บ badssl

เริ่มจาก ส่งไปว่า Record Layer คือเวอร์ชั่น 1.0 นะ (ขีดเส้นใต้สีแดง)

และ Handshake Protocol เป็น TLS 1.2 นะ (เส้นใต้สีม่วง)

ผมมี Cipher Suites รองรับกระบวนการเข้ารหัสทั้งหมด 17 อัลกอริทึมนะ ถ้าเว็บ badssl ตอบกลับมาก็เลือกเอาได้ตามนี้

ข้างล่างมี extension อีกเหมือนกันนะ

มาพิจารณากันในจังหวะแรกที่ตะโกนถามด้วย TLS เข้าไปหาเว็บ badssl เราก็บอกเขาไปว่า TLS Record Layer ที่ส่งไปบอกเว็บ คือจะบอกว่า “ฉัน Client Microsoft Edge ยอมรับการใช้ TLS เวอร์ชั่นย้อนหลังให้เธอได้เท่านี้นะ ในตัวอย่างก็คือ ยอมรับได้แค่ TLS 1.0 นะเออ”

ส่วนฟิลด์ TLS Handshake Protocol ส่งไปบอกว่า “ฉันพร้อมที่จะตกลงกับเธอ ที่ TLS 1.2 นะ”

ok นะ สองฟิลด์นี้สำคัญ และตีความแตกต่างกันได้

Random : เป็นกลุ่มเลข 32 Byte ที่สุ่มขึ้นมา เพื่อจะใช้เป็นองค์ประกอบการเข้ารหัส แล้วรับส่งกันในลำดับต่อไป

Session ID : เป็นหมายเลข session ที่ใช้ส่งเข้าไปเชื่อมต่อกับเว็บ badssl เมื่อ web server ของ badssl ได้รับเลขนี้ไป มันจะไปหาว่ามีเลขนี้อยู่ในแคชของ server มั้ย ถ้ามีก็จะ resume connection เดิมที่ค้างไว้ก่อนหน้าได้ , ถ้าค้นหาแล้วไม่เจอก็จะเป็นการสร้างใหม่

Cipher Suit : คืออัลกอริทึมที่บอกเว็บ badssl ว่า ฉัน (Microsoft Edge ของภานุพงษ์) รองรับการเข้ารหัสลับด้วยอัลกอริทึมเหล่านี้นะ ภาพก็ Wireshark ข้างบนดูเอาว่ามีอัลกอริทึมอะไรบ้าง 17 อันนั่นแหละ ส่วนตัวอย่างวิธีการตีความหมายก็ตามนี้เลย

Cipher Suites in TLS/SSL (Schannel SSP) — Win32 apps | Microsoft Learn

STEP ที่ 2: Server Hello

หลังจากจบ Step 1 เว็บ badssl ได้รับ Client Hello จากผม เว็บก็จะทำการตอบกลับมาที่คอมผมด้วย Server Hello มาดูกันว่าตอบกลับอะไรมาบ้าง , Wireshark โลด

ขากลับก็จะเห็นว่า web server เครื่องนี้ยังใช้ TLS 1.2 อยู่ ต่างตอบ TLS Handshake Protocol มาตรงกันทั้ง 2 จุดประสงค์ ที่ผมขีดเส้นใต้ไว้สองสี ตรงนี้มีความหมายมากครับ

เพราะมันหมายความว่า “แม้ Client จะยอมรับ TLS ย้อนหลังไปถึง 1.0 ก็จริง แต่ Web Server เลือกที่จะไม่ยอมรับครับ ผู้ดูแลระบบเว็บเขาจะบังคับให้ client ต้องใช้ 1.2 สูงขึ้นไปกว่านี้เท่านั้น”

ถ้าจะติดต่อกับเว็บ badssl วันนี้ — ใครใช้ browser เก่าๆ ที่ไม่มีแม้แต่ TLS1.2 คือเป็น TLS 1.1 ลงไป ก็จะเข้าใช้งานเว็บ badssl ไม่ได้เลย ซึ่ง web Browser ที่รองรับ TLS 1.1 มันเก่าขนาดไหนกันล่ะ ? ผมยกมาอันนึงแล้วกัน มันก็คือ Firefox ESR เวอร์ชั่น 28 ครับ คือย้อนสมัยเมื่อช่วง 9–11 ปีที่แล้วโน่นนนนนนนนน สมัยยิ่งลักษณ์ ชินวัตรอะครับๆ ถ้าใครยังใช้ firefox เวอร์ชั่นเก่าอันนี้ มาจนถึงวันนี้ ผมก็ไม่รู้จะพูดยังไงแล้ว คงจะไม่คิดจะอัพเกรดอะไรเลยจริงๆ ยอมใจครับ

733647 — Implement TLS 1.1 (RFC 4346) in Gecko (Firefox, Thunderbird), on by default (mozilla.org)

ภาพที่เห็นนี้ก็คือเป็นภาพของการแจ้งบัค firefox ซึ่งได้โพสต์ไว้ว่า เฮ้ย ต่อไปนี้เอ็งน่ะ ใช้ TLS 1.1 เป็น default ได้แล้วนะ แต่ก็เป็นการโพสต์เมื่อ 11 ปีที่แล้วนั่นแหละครับ ซึ่งเราสามารถเข้าไปดูใน Wikipedia ได้ครับว่า แต่ละ browser ยอดนิยม รองรับ TLS 1.0 / 1.1 / 1.2 / 1.3 ตั้งแต่เวอร์ชั่นไหน

คลิกลิ้งนี้ Version history for TLS/SSL support in web browsers — Wikipedia

แน่นอนครับ ถ้าเราต้องการความปลอดภัยสูงสุด ก็ต้องเป็น TLS 1.3 หรือชุด update software ที่ใหม่ที่สุด แก้ bug stable แล้วนั่นเองครับ

เอาล่ะ มาตรง Server Hello กันต่อครับ

Random : เหมือนกับตอน Client Hello ครับ เป็นกลุ่มเลข 32 Byte ที่สุ่มขึ้นมา เพื่อจะใช้เป็นองค์ประกอบการเข้ารหัส แล้วรับส่งกันในลำดับต่อไป ผม Ctrl+C แล้ว Ctrl+V เลย ง่ายมั้ยครับ แฮร่ !!

Session ID : เป็นหมายเลข session ที่เว็บ badssl ส่งกลับมาให้คอมผมนั่นเอง จะสังเกตว่า มันเป็นคนละเลขกับตอน Client Hello ครับ เพราะเนื่องจากว่า server ของ badssl ได้รับเลขตอน Client Hello มาแล้ว มันจะไปหาว่ามีเลขนี้อยู่ในแคชของ server มั้ย ถ้ามีก็จะ resume connection เดิมที่ค้างไว้ก่อนหน้าได้ , ถ้าค้นหาแล้วไม่เจอก็จะเป็นการสร้างใหม่

ปรากฎว่าค้นหาแล้วไม่มี จึงส่งเลข Session นี้ไปแล้วบอกว่า เอ็งน่ะ ใช้ session id นี้คุยกับข้าต่อนะ

ซึ่งมันก็สอดคล้องกับความจริงด้วย เพราะวันๆ ผมไม่ได้เข้าหรอกครับเว็บนี้ ผมเข้าแต่เว็บอื่น !! แต่เข้าครั้งแรกตอนนี้ เพื่อยกตัวอย่างนี่แหละ !

Cipher Suites : ครั้งนี้ Server จะเป็นผู้เลือกแล้ว ว่าจะใช้อัลกอริทึมอะไร ในการเข้ารหัสครับซึ่งเว็บได้เลือกการเข้ารหัสแบบ TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 ร้องขอมายังเครื่องผมครับว่า เราจะตกลงเข้ารหัสกันด้วยอัลกอริทึมนี้นะ เพราะเอ็งก็เสนอมา 17 อัน ข้าเลือกอันนี้แล้วกัน เพราะมัน “แข็งแรงที่สุดใน 17 อันที่เอ็งส่งมา”

แปลเป็นไทยทีละตัว

TLS_ = บอกว่าเป็นโปรโตคอล TLS นะ (ไม่ใช่ SSL)

ECDHE_= บอกว่า ใช้โปรโตคอลนี้ในการแลกเปลี่ยนคีย์

RSA_ = บอกว่า ใช้อัลกอริทึมเข้ารหัส/ถอดรหัสนี้ ในการยืนยันตัวตน

WITH_ = บอกว่า ข้างหน้าคือ asymmetric นะ กับข้างหลัง Symmetric นะ “กับด้วย”

AES_ = บอกว่า ใช้อัลกอริทึมเข้ารหัส/ถอดรหัสนี้ ในการรับส่งข้อมูล

256_ = บอกว่า อัลกอริทึม AES ข้างหน้าแข็งแรงขนาดไหน (จำนวนบิต)

GCM_ = บอกว่า Mode ที่ใช้ในการเข้ารหัสเป็นอะไร Galois/Counter Mode

SHA384_ = บอกว่า รูปแบบของ Message Authentication Code หรือ PRF ใช้รูปแบบอะไร

ทั้งหมดนี้คือ Cipher Suit ที่ badssl เลือกหลังจากที่ผมใช้ Microsoft Edge ส่ง Client Hello ไป

Compression Method : กระบวนการบีบอัดในระหว่างรับส่ง Client <> Server กระบวนการนี้จะช่วยให้ประยัด Bandwidth มากขึ้น แต่ก็มักจะตามมาด้วยช่องโหว่ทาง Cryptography ครับ เช่นนั้นการ config web server เขาจึงมักจะเลือกเป็น null คือเว็บ badssl ก็จะบอกคอมผมว่า TLS ที่เราจะคุยกันอย่างปลอดภัย จะไม่บีบอัด นั่นเองครับ

สุดท้ายของ server hello ก็จะมี extension ครับ แต่จะน้อยกว่าตอน client hello ผมไม่ขอแค็ปมาโชว์แล้วกัน

STEP ที่ 3: Server certificate

หลังจากคอมผมได้รับ Server Hello มาแล้ว คอมผมจะยังไม่ทำอะไรต่อ จนกว่า Server จะส่งใบรับรอง digital มาครับ

ดูตรงขีดเส้นใต้สีม่วงจะเห็นว่า ไม่ใช่ Client/server hello แล้ว แต่ handshake protocol จะเป็นเรื่อง Certificate ซึ่งในครั้งนี้ server ส่ง certificate มาให้คอมผมด้วยขนาดถึง 4020 byte อย่างว่า องค์ประกอบของใบ Certficiate มันก็เยอะ ผมแตะ expand ไม่ไหวมันยาวและถ้าจะลงรายละเอียดอาจจะยาวเกินไปมากสุดๆ สำหรับบทความนี้ แต่สรุปคือ web server ส่งใบ cert กลับมาครับ

STEP ที่ 4: Server ก็ยังต้องส่ง key มา (Server Key Exchange) , และส่ง Server Hello done มาเพื่อบอกว่าฝั่งนี้เรียบร้อยแล้ว

ขั้นตอนนี้เป็นขั้นตอนที่สำคัญมาก มันคือขั้นตอนแลกเปลี่ยนคีย์ , อาจจะมีคำถามว่า แลกเปลี่ยนทำไมล่ะ ? เอางี้ เอาเป็นว่า โดย Server จะเป็นฝ่ายส่งมา key มาให้ก่อน แน่นอนมันต้องเป็น public key ที่มาคู่กับ certificate ครับ ดังนั้น Hello ก่อหน้านั้นมันก็ยังไม่หมด เลยต้องส่งให้ครบ และจบ server hello สักที , มาดู Wireshark กันดิ

ก็จะเห็นว่า web server ส่ง public key มาด้วยครับ 65 byte และลายเซ็นดิจิตอลมาด้วย 256 byte

ตอนนี้คอมผมได้รับอะไรแล้วบ้าง

ได้รู้ว่า ใช้อัลกอริทึมไหน ในการเข้ารหัส

ได้รู้ว่า เว็บ server ปลายทางมีใบรับรองดิจิตอลอะไร แถมยืนยันได้ด้วยถ้าจะยืนยัน

ได้ public key ของ server มาแล้ว เป็นองค์ประกอบสำหรับเข้ารหัสลับข้อมูลได้แล้ว

เอาล่ะ ตาคอมผมส่งกลับไปบ้าง

STEP ที่ 5: Client Key Exchange, Change Cipher Spec, Encrypted Handshake Message

รออะไร Wireshark เลยครับ ตรงไปตรงมาที่สุดแล้ว !

การส่งกลับไปครั้งนี้ ส่วนแรกคือการที่คอมผมสร้าง session key ขึ้นมา (ในกรอบสีแดงครับ) มองว่าเป็น public key ของคอมผมก็ได้ หรือถ้าเป็นอัลกอริทึมแลกเปลี่ยนคีย์อันอื่น ก็อาจจะถูกเรียกว่าเป็น pre master key ก็ได้ ,, การส่งคีย์นี้กลับไปเพื่อเป็นการแลกเปลี่ยนคีย์ซึ่งกันและกันระหว่าง Client กับ server (Client Key Exchange) นั่นแหละครับ 65 byte

session key คอมผมอันนี้ “เข้ารหัสลับ” นะครับ ที่โชว์อยู่ใน wireshark กรอบแดง นั่นคือเป็น cipher text แล้ว ซึ่ง session key ที่แท้จริงนั้นถูกล็อค เข้ารหัสด้วย public key ของ server ครับ เพื่อส่ง session key ให้ server อย่างปลอดภัยนั่นเอง และจะเป็น server อันเดียวเท่านั้นที่มี private key คู่ของมันอยู่ถึงจะถอดรหัสออกมาจาก public key ของตัวเองได้

server จึงได้ session key ของคอมผมไปสำเร็จ

key นี้ก็จะเอาไว้ใช้ร่วมกัน (shared key) ในการเข้ารหัสและถอดรหัส ในทุกๆจังหวะรับส่งข้อมูล

เราจะเห็นว่า ขั้นตอนแลกเปลี่ยนคีย์

server ส่งให้ cert+public key ให้ client > จะเป็นแบบ asymmetric เพราะ server เก็บ private key ไว้กับตัวเอง (ล็อคกับปลดล็อค คนละกุญแจ)

client ส่ง session key ไปให้ server > จะเป็นแบบ asymmetric เช่นกัน เพราะ client เอา public key ของ server มาเข้ารหัส session key แล้วส่ง cipher text กลับไป (ล็อคกับปลดล็อค คนละกุญแจ)

…………. เมื่อเราได้กุญแจ ที่ยืนยันตัวตนว่าปลอดภัย ไม่ใช่คนอื่น ระหว่างเราได้ แน่ๆแล้ว ฉันใดก็ฉันนั้น เราจึง ………………………..

………… ต้องการกุญแจ 1 ดอกก็พอ สำหรับทั้ง session ……….

………… สำหรับข้อมูลรับ ข้อมูลส่ง …….ไม่ใช่การ handshake

…………. กุญแจดอกเดียว เข้ารหัส/ถอดรหัส ได้ตลอดทั้ง session แปลว่านี่คือการเข้ารหัสแบบ symmetric …………….

………… แต่ก่อนจะแลกกุญแจกัน ต้องแลกกุญแจนี้ด้วยกันอย่างปลอดภัย …………

…………. เราจึงต้องหวังพึ่งพา asymmetric ในตอนแรก เพื่อแลกเปลี่ยนกุญแจ session key ก่อน นั้นเอง ……….

………. ข้อเสียของ asymmetric คือเข้าและถอดรหัสได้ช้ากว่า symmetric ……..

……… เพราะถ้าเราใช้ asymmetric ในส่วนของที่เป็นข้อมูลจริง (ไม่ใช่ handshake) , CPU ของทั้งสองฝั่งจะรับภาระในการเข้าและถอดรหัสเยอะมาก ยิ่งถ้าฝั่ง server มีการเรียกข้อมูลจาก client เป็นพัน หมื่น แสน ล้าน เครื่อง server อาจจะตอบสนองไม่ได้ …….ก็เป็นได้

เหมือนเขียนซ้ำ เขียนขยี้ วนไปมา แต่มันก็เป็นยังงี้แหละครับ

เราต้องมองจังหวะของความแตกต่าง ให้ออกครับ

พ่วงด้วยการ Change Cipher Spec คือเป็นการบอก server ว่าเครื่อง client พร้อมแล้วสำหรับการรับส่งข้อมูลแบบเข้ารหัส ขั้นตอนก่อนหน้า คือข้าและเอ็ง ทำข้อตกลง handshake กันเรียบร้อย (เรามีของพร้อมทุกอย่างในการเข้ารหัสและถอดรหัส) หลังจาก TLS record นี้จะเป็นการรับส่งข้อมูลที่เข้ารหัสแบบ สมมาตร (symmetric) จากที่ได้ตกลงเรื่อง shared key กันไว้

STEP ที่ 6: Server ตอบ Change Cipher Spec, และเริ่มรับส่ง Encrypted Handshake Message

ถ้า เธอพร้อมฉันก็พร้อม

ถ้า client ตอบว่า Change Cipher Spec , Server ก็ตอบเช่นกัน หลังจากนั้นก็อาจจะมีการระบุระยะเวลาด้วย ตามตัวอย่างคือ TLS Session Ticket 300 วินาที (ครบ 5 นาทีถ้ามีการสื่อสารอยู่ จะ New Session Ticket ใหม่) , Wireshark ครับ

ต่างคนต่างได้ share key กันไปอย่างปลอดภัยแล้ว ต่อไปก็รับส่ง data ที่เข้ารหัสลับ กันรัวๆ ใน Wireshark จะถูกเรียกว่า application data และข้อมูลในฟิลด์ จะมองเป็น Encrypted Application Data

ซึ่งถ้า ใครสักคน เช่น รัฐบาลผู้รักเรา อยากจะแกะดูเนื้อหาที่เรารับส่งระหว่างทาง ว่าไอ้ภานุพงษ์ มันไปทำอะไรที่ badssl เขาจะอ่านไม่รู้เรื่องเพราะมันถูกเข้ารหัสไปแล้ววว (ตัวผมเอง ใช้ wireshark capture มายังอ่านไม่รู้เรื่องเลย)

ถ้าอยากจะถอดรหัส ก็ต้องหา key มาให้ได้

วิธีการได้มาซึ่ง session key คือเราต้องเปิดให้มันบันทึกเอาไว้ในคอม ไม่ใช่หายไปจาก memory เอาเป็นว่า ไม่เขียนแล้วกัน ใครอยากรู้ก็ google > decrypt tls wireshark

แค่นี้แหละครับ TLS

…………..

นี่คือขั้นตอนที่ยุบยับของ TLS 1.2 ครับ

แต่ TLS 1.3 ย่อขั้นตอนพวกนี้ลงมาให้ง่ายกว่าเดิมอีก และปลอดภัยมากกว่าเดิมด้วยครับ

มีแค่นี้ครับ

TLS Security 5: Establishing a TLS Connection | Acunetix

ไม่ต้องมีขั้นตอน Change Cipher Spec ครับ เพราะตอน Client Hello ส่งไปก็เป็นการบอกตอนแรกเลย ว่าพร้อมจะรับส่งข้อมูลแบบเข้ารหัสแทบจะทันทีแล้ว

TLS 1.3 ก็ยังรองรับการสื่อสารกับเครื่องที่ยังไม่ได้อัพเดต (เช่น เราพร้อม 1.3 แล้วแต่อีกฝั่งยังเป็น TLS 1.2 อยู่) คือ backward compatibility แต่ตรงนี้จะอยู่ใน extension แทนครับ และ TLS 1.3 นี่อัด extension แบบสุดๆ Entension , Extension everywhere !

แนวคิดในการใช้งานแบบ default คือระบบจะเลือกอัลกอริทึมที่แข็งแรงที่สุดในการเข้ารหัสอยู่เสมอ เช่นนั้นแล้วถ้าเป็นไปได้ ควรอัพเดตโปรแกรมให้ทันสมัย ใหม่ ปลอดภัยกว่าครับ เพราะผู้พัฒนา โดยเฉพาะทางด้าน security จะมีการพัฒนาเรื่องพวกนี้ให้แข็งแกร่งขึ้น ทนทานในการเจาะมากขึ้น และยกเลิก อัลกอริทึม ที่มีช่องโหว่ หรือมีปัญหา ออกไป

ผมเชื่อว่าบทความนี้น่าจะให้อะไรกับหลายๆท่าน ได้บ้าง

• ได้รู้ว่า TLS ทำงานยังไง
• ได้รู้ว่า ใบรับรองดิจิตอล สำคัญยังไงกับเว็บ
• ได้ความเข้าใจที่ถูกต้องระหว่าง SSL กับ TLS
• ได้รู้ว่าทำไมบางประเทศ บางรัฐบาล บางองค์กร ถึงอยากจะกำหนด root certificate ลงไปใน gateway ของระบบตัวเอง (เพราะมี root cert ก็ = มี private key , มี private key ก็ = decrypt ถอดรหัสทุกข้อมูลของคู่กุญแจที่สื่อสารได้)

The 2021 TLS Telemetry Report | F5 Labs

ทั้งนี้ ยังมีอีกหลายๆ ส่วนที่ยังขาดไป เช่น กระบวนการ certificate ที่ละเอียดกว่านี้ , การเอา certificate ไปยัดใน web server , ทำไมใน ระบบปฏิบัติการถึงมี certificate ฝั่งอยู่เยอะแยะ

การใช้ TLS กับ protocol อื่นๆ นอกจาก HTTP , ท่าทางอื่นๆ ของ TLS เช่นพวก extension , รวมไปถึงช่องโหว่ ต่างๆ ฯลฯ

ผมต้องขออภัย อันนี้จะเขียนเพื่อให้ทราบที่มาที่ไป ของ TLS ประมาณหนึ่ง เรื่องขยายอื่นๆ อาจจะขอรวบไว้เป็นโอกาสหน้า หากได้คอมเม้น ได้อะไรหลายๆ อย่างมากพอ ผมจะมาเขียนใหม่ครับ

และหากตรงไหนที่ผม ขาดตกบกพร่องไป หรือข้อมูลตรงไหนควรได้รับการแก้ไข รบกวนแจ้งมาได้ เพื่อแก้ไขให้ถูกต้อง น้อมรับข้อผิดพลาดครับ

ขอบคุณครับ ที่ติดตาม และอ่านจนจบ เจอกันใหม่บทความหน้าครับ

สวัสดีครับ