เหตุผลที่ SSL ถูกเปลี่ยนชื่อเป็น TLS ในช่วงปลายทศวรรษ 1990

 (tim.dierks.org)
1 คะแนน โดย GN⁺ 2025-06-16 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในช่วงกลางทศวรรษ 1990 ท่ามกลาง สงครามเบราว์เซอร์ เมื่อมีความเป็นไปได้สูงที่ SSL ของ Netscape และ PCT ของ Microsoft จะแยกทางกัน อุตสาหกรรมจึงพยายามรวมสิ่งเหล่านี้ให้เป็นมาตรฐานเปิดเดียว
  • SSL รุ่นแรกมีข้อบกพร่องจนไม่ได้ออกเผยแพร่ และแม้ SSL 2 ซึ่งเป็นเวอร์ชันแรกที่ใช้งานจริงจะถูกใช้มาหลายปี แต่ก็มีข้อจำกัดทั้งด้านวิทยาการเข้ารหัสและการใช้งานจริง
  • PCT ของ Microsoft เป็นส่วนขยายของตนเองที่ต่อยอดจาก SSL 2 และปรับให้เข้ากับ IE และ IIS ส่วน Netscape ตอบโต้ด้วย SSL 3.0 เพื่อไม่ให้เสียอำนาจนำด้านมาตรฐาน
  • Netscape และ Microsoft เห็นพ้องกับ กระบวนการกำหนดมาตรฐานแบบเปิด ของ IETF แต่ต้องหลีกเลี่ยงภาพที่ดูเหมือนว่า IETF เพียงแค่รับรองโปรโตคอลของ Netscape ตามเดิม
  • ท้ายที่สุด SSL 3.0 จึงมีการเปลี่ยนแปลงบางส่วนและเปลี่ยนชื่อด้วย โดย TLS 1.0 เริ่มต้นในรูปแบบที่แทบจะใกล้เคียงกับ SSL 3.1

SSL และ PCT ท่ามกลางสงครามเบราว์เซอร์

  • ในช่วงกลางทศวรรษ 1990 การแข่งขันเบราว์เซอร์ระหว่าง Netscape กับ Microsoft ส่งผลต่อการกำหนดมาตรฐานโปรโตคอลความปลอดภัยด้วย
  • Netscape พัฒนา โปรโตคอล SSL
    • เวอร์ชันแรกมีข้อบกพร่องด้านวิทยาการเข้ารหัส ถูกเจาะได้อย่างรวดเร็ว และไม่ได้ออกเผยแพร่
    • เวอร์ชันสำหรับโปรดักชันแรกคือ SSL 2 และถูกใช้งานอยู่หลายปี
    • SSL 2 มีข้อบกพร่องทั้งด้านวิทยาการเข้ารหัสและการใช้งานจริง แต่ไม่ใช่วิกฤตที่รุนแรงถึงขั้นต้องเปลี่ยนทันที
  • Microsoft แก้ไข SSL 2 และเพิ่มส่วนเพิ่มเติมของตนเองเพื่อกำหนดเป็น PCT
    • PCT เป็นโปรโตคอลที่แตกแขนงมาจาก SSL 2
    • ขอบเขตการรองรับจำกัดอยู่ที่ IE และ IIS
  • Netscape ก็พยายามแก้ปัญหาของ SSL 2 เช่นกัน แต่ไม่ต้องการให้ Microsoft ได้อำนาจนำหรือความเป็นเจ้าของมาตรฐานไป
    • ผลลัพธ์คือการพัฒนา SSL 3.0 ที่มีการเปลี่ยนแปลงขนาดใหญ่กว่า

การกำหนดมาตรฐานของ IETF และชื่อ TLS

  • หลายคนในอุตสาหกรรมและชุมชนพยายามหลีกเลี่ยงสถานการณ์ที่โปรโตคอลเกิดการ fork
  • Consensus Development เป็นเจ้าภาพการประชุมที่ตัวแทนจาก Netscape และ Microsoft มาพบกัน
    • Tim Dierks ทำงานที่ Consensus Development ร่วมกับ Christopher Allen ในขณะนั้น
    • เขาเขียน reference implementation ของ SSL 3.0 ภายใต้สัญญากับ Netscape
    • Bruce Schneier เข้าร่วมการประชุม และ Paul Kocher ผู้ซึ่งออกแบบโปรโตคอล SSL 3 ก็น่าจะเข้าร่วมด้วย ส่วน Microsoft มี Barbara Fox เป็นตัวแทน
  • ผลจากการเจรจา Microsoft และ Netscape ตกลงให้ IETF รับช่วงโปรโตคอลไปและ กำหนดเป็นมาตรฐานผ่านกระบวนการเปิด
    • กระบวนการนี้นำไปสู่การที่ Tim Dierks เป็นบรรณาธิการ RFC
  • ระหว่างกระบวนการกำหนดมาตรฐาน SSL 3.0 มีการเปลี่ยนแปลงบางส่วน
    • มีเป้าหมายเพื่อไม่ให้ดูเหมือนว่า IETF เพียงแค่รับรองโปรโตคอลของ Netscape อย่างตรงไปตรงมา
    • ด้วยเหตุผลเดียวกัน ชื่อของโปรโตคอลก็ถูกเปลี่ยนด้วย
  • TLS 1.0 ที่ถือกำเนิดขึ้นเช่นนี้ จริง ๆ แล้วเป็นเวอร์ชันที่ใกล้เคียงกับ SSL 3.1

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

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

 
GN⁺ 2025-06-16
ความคิดเห็นใน Hacker News

  • หมายเลขเวอร์ชันไม่ได้สื่อความแตกต่างของโปรโตคอลได้ดี เลยยิ่งทำให้สับสน
    SSLv2 เป็น SSL ตัวแรกที่ถูกใช้งานอย่างแพร่หลาย แต่มีปัญหาเยอะ ส่วน SSLv3 แทบจะเป็นโปรโตคอลใหม่เลย
    TLS 1.0 คล้ายกับ SSLv3 แต่มีการแก้เล็กน้อยในกระบวนการทำให้เป็นมาตรฐานของ IETF และ TLS 1.1 เป็นการปรับแก้เล็กมากเพื่อแก้ปัญหาวิธีใช้ block cipher
    TLS 1.2 เป็นการปรับแก้ระดับกลางเพื่อตอบรับจุดอ่อนของ MD5 และ SHA-1 โดยเพิ่มแฮชใหม่และ ชุดรหัสลับแบบ AEAD เช่น AES-GCM ส่วน TLS 1.3 แม้จะนำองค์ประกอบบางส่วนก่อน TLS 1.2 มาใช้ซ้ำ แต่โดยมากแล้วแทบจะเป็นโปรโตคอลใหม่
    โปรโตคอลเหล่านี้ทั้งหมดถูกออกแบบให้เจรจาเวอร์ชันอัตโนมัติได้ ทำให้ไคลเอนต์กับเซิร์ฟเวอร์สามารถอัปเกรดแยกกันได้โดยไม่เสียการเชื่อมต่อ

    • TLS 1.0 นำ ความเป็นโมดูลาร์ เข้ามาด้วยแนวคิด “extension” จึงยากจะมองว่าเป็นวิวัฒนาการเล็กน้อย
      หนึ่งในนั้นคือ session ticket ที่ทำให้ฝั่งเซิร์ฟเวอร์ resume session ได้โดยไม่ต้องมี state ที่ซิงก์กันระหว่างเซิร์ฟเวอร์ และอีกอย่างคือ Server Name Indication ที่ทำให้เซิร์ฟเวอร์ใช้ใบรับรองได้มากกว่าหนึ่งใบ
    • การเจรจาเวอร์ชันอัตโนมัติยังทำให้เกิด การโจมตีแบบดาวน์เกรด หลายแบบมาตลอดหลายสิบปี
    • ควรเรียก TLS 1.0 ว่า TLS v4.0 ไปเลยมากกว่า
      การทำเวอร์ชันต่อมาเป็น v1.1, v1.2, v1.3 ก็ดูเหมือนความดื้อดึงที่ไม่อยากยอมรับว่าการรีเซ็ตหมายเลขเวอร์ชันนั้นผิดในเชิงวัตถุวิสัย
    • แต่อย่างน้อยก็ไม่ได้ตั้งเวอร์ชันตามปี

  • ตอนนั้น Microsoft เป็นคนละสัตว์ร้ายโดยสิ้นเชิง ดังนั้นความสับสนเรื่องชื่อ SSL/TLS จึงไม่ได้รู้สึกแปลกขนาดนั้น
    M$ ในยุคนั้นพยายามจะควบคุมทุกอย่าง และผมมองว่าพวกเขายังไม่หยุดความพยายามที่จะชะลอเทคโนโลยีอินเทอร์เน็ตแบบโอเพนซอร์สจนถึงต้นทศวรรษ 2010 ด้วยซ้ำ
    พวกเขาทำให้ Java Applet ตายได้สำเร็จ และผมคิดว่ายังทำให้ JavaScript กับ CSS โดยรวมล้าหลังไปหลายปีด้วย
    ช่วงต้นทศวรรษ 2000 บริษัทกดดันให้รองรับ “เทคโนโลยี” ล่าสุดของ IE แต่พอบั๊กหลักของ JS ถูกแก้ เราก็เริ่มรองรับ Mozilla 3.0 ทันที และภายหลังมันกลายเป็นการตัดสินใจที่ดี เมื่อบริษัท Fortune 500 แห่งหนึ่งเริ่มใช้ Mozilla/Firefox กับแอปภายในตั้งนานก่อนที่มันจะแพร่หลาย

    • ผมไม่คิดว่า Microsoft เป็นคนฆ่า Java Applet
      บน IE มันทำงานได้เสมอ และนั่นแทบจะเป็นช่องทางเดียวที่ Microsoft มีอิทธิพลได้
      Applet ล้มเหลวเพราะกลายเป็นตัวอย่างเด่นของคำว่า “Java ช้า” ซึ่งแม้โดยทั่วไปจะไม่จำเป็นต้องจริง แต่กับ Applet นั้นจริงเพราะต้องรอดาวน์โหลดและ รอ JVM เริ่มทำงาน
      สุดท้าย HTML/JS ก็ทำฟีเจอร์ไดนามิกที่เมื่อก่อนต้องใช้ Applet ได้ดีกว่า และส่วนที่ HTML ยังทำไม่ได้ก็ถูก Flash เอาไป ทำให้มันหายไป
    • Applet ตายด้วยหลายเหตุผล
      แค่อนิเมชันเล็ก ๆ อย่างเดียวก็มี เวลาเริ่มต้น JRE ที่ยาวจนน่าขัน ตามมาตรฐานยุคนั้นยังต้องการหน่วยความจำสูงและแครชหนัก อีกทั้งปัญหาความเข้ากันได้ของ Java platform รุ่นแรก ๆ ก็แปลกมาก
      โมเดลความปลอดภัยที่ตั้งอยู่บนสมมติฐานว่าผู้ที่ขอใบรับรอง CA ได้จะเป็นฝ่ายดีนั้นก็น่าขำ และเทคโนโลยี sandbox ของเบราว์เซอร์โดยรวม ไม่ใช่แค่ IE ก็ยังไม่成熟
    • ผมว่า ชื่อเล่น “M$” เหมาะกับยุคนี้มากกว่า
    • Microsoft ไม่ได้เปลี่ยนไปมากนัก นอกจากฝ่ายประชาสัมพันธ์ที่ดีขึ้น
    • Amazon ก็มี https://github.com/aws/s2n-tls ด้วย
      เคยคาดหวังกับ s2n ไว้มาก แต่ดูเหมือนมันจะไม่ได้ปักหลักมากนักนอก AWS

  • คนที่แยก TLS กับ SSL อย่างเข้มงวดคือคนที่รู้ความต่างและมองว่าคู่สนทนาก็ควรรู้ด้วย แต่ในทางปฏิบัติมันคล้ายความต่างระหว่าง .doc กับ .docx
    โดยพื้นฐานแล้วต่างกัน แต่สำหรับผู้ใช้ทั่วไปดูเหมือนใช้แทนกันได้ และหน้างานส่วนใหญ่ก็สนใจแค่ว่า HTTPS ใช้งานได้หรือไม่ ไม่ได้ใส่ใจกลไกภายในมากนัก

    • ความยากหลักคือการอธิบายให้ผู้ใช้ทั่วไปเข้าใจว่า TLSv1.0 ใหม่กว่าและดีกว่า SSLv2/SSLv3
      จำได้ว่าเคยถกกับคนจำนวนไม่น้อยที่คิดว่าตัวเลขยิ่งมากยิ่งดี
    • แม้ SSL จะถูกเลิกใช้มานานแล้ว ผู้คนก็ยังใช้คำว่า SSL เป็นชื่อเรียกทราฟฟิกเครือข่ายที่เข้ารหัส
      ถ้าเรียกทราฟฟิกเครือข่ายเข้ารหัสสมัยใหม่ทั้งหมดว่า TLS และเรียก SSL เฉพาะตอนที่ต้องใช้ SSL เพราะระบบเลกาซีจริง ๆ น่าจะง่ายกว่ามาก

  • เมื่อกี้เพิ่งรู้ตัวว่าสมองผมแยก SSL กับ TLS ได้ยากโดยไม่รู้ตัว
    ผ่านมา 20 ปีถึงเพิ่งเข้าใจว่าทำไม

    • ผมก็เหมือนกัน
      อยู่ในวงการนี้มา 15 ปี เพิ่งเข้าใจจริง ๆ ว่า ssl กับ tls คือสิ่งเดียวกัน เลยรู้สึกเหมือนตัวเองโง่ไปเลย
    • ผมรู้ราว ๆ ปี 2010 แต่ก่อนหน้านั้นก็ไม่รู้เหมือนกัน
      จุดเริ่มคือใน Java แม้จะใช้ TLSv1.3 ในปัจจุบัน เวลาเริ่มการเชื่อมต่อแบบเข้ารหัสก็ยังใช้ SSLSocket อยู่

  • “Transport Layer Security” เป็นชื่อที่ดีกว่าจริง ๆ
    การพูดว่า “TLS” ก็ดี และ SSL ที่มี S ติดกันสองตัวฟังดูเหมือนงู

    • ปัญหาคือ TLS ถูกใช้แพร่หลายในฐานะตัวย่อของ thread local storage อยู่แล้ว
      Transport Layer Security มีเอกสารแพร่หลายว่าเริ่มในปี 1999 ส่วน “Thread Local Storage” มีเอกสารที่ย้อนกลับไปได้อย่างน้อยถึงปี 1996
      ตอนนั้นเป็นคำที่พบบ่อยกว่าฝั่ง Microsoft หรืออาจรวมถึง IBM/OS/2 ส่วนใน Pthreads และ Unix โดยรวมมักเรียกว่า “thread-specific data”
      เอกสาร Itanium ABI ปี 2001 อาจช่วยแพร่คำนี้ไปในโลก Unix ที่กว้างขึ้น แต่ดูเหมือน Sun ก็ใช้คำนี้มาก่อนแล้วในฝั่ง Solaris และ Java
    • ผมกลับคิดว่า SSL เป็นชื่อที่เข้ากว่า
      ในทางทฤษฎี TLS อาจเป็นกลไกความปลอดภัยระดับ transport layer ที่เอาโปรโตคอลใด ๆ มาวางทับได้เหมือน IPSec แต่ในทางปฏิบัติมันแทบจะผูกกับ TCP socket
      ตัวแปรสำหรับ UDP อย่าง DTLS หรือ QUIC ก็ไม่ได้เป็นส่วนหนึ่งของสเปก TLS และแม้จะมี kernel TLS ของ Linux หรือโครงสร้างพื้นฐานคล้ายกันของ Windows ก็ไม่ได้ง่ายถึงขั้นเปิด TLS ด้วย socket flag แค่ตัวเดียว
    • “SSL” ออกเสียงง่ายกว่า “TLS” เพราะตำแหน่งลิ้นแทบไม่เปลี่ยนระหว่างตัวอักษรสามตัว
    • ชื่อที่ดีที่สุดคือชื่อแรกที่ออกมาแล้วติดตลาด

  • สงสัยว่าเวลาจะบอกใครสักคนว่าต้องเข้าเว็บไซต์อย่างปลอดภัย หรือในสถานการณ์ที่ควรใช้คำว่า TLS/SSL ปกติพูดกันว่าอะไร

    1. เรียกว่า SSL หรือ TLS
    2. อายุเท่าไร หรือเริ่มทำงานก่อนปี 1999 หรือไม่
    • ปกติจะพูดว่า SSL
      เป็นเวลานานที่ไม่รู้ด้วยซ้ำว่า TLS เป็น “สิ่งเดียวกัน” หรือเปล่า และถึงตอนนี้จะรู้แล้ว 9 ใน 10 ครั้งก็ยังเรียกว่า SSL อยู่ดี
      อายุ 38 ปี เริ่มทำงานปี 2011 แต่เคยลองเขียนโปรแกรมเครือข่ายครั้งแรกประมาณปี 2004~2005
      เมื่อกี้มองไปอีกหน้าจอ ก็เห็นว่าฟังก์ชันที่เพิ่งเพิ่ม if statement ไปเมื่อไม่กี่นาทีก่อนยังใช้ชื่อว่า sslCertNotBefore อยู่เลย
      คิดว่าส่วนหนึ่งของปัญหาคือโปรแกรมเมอร์โดยทั่วไปไม่ได้จัดการ TLS โดยตรง
      เคยสร้างระบบที่ดึงข้อมูลใบรับรองแบบละเอียดจากการเชื่อมต่อ HTTPS ซึ่งการดึงข้อมูลที่ต้องการออกจาก Java standard library ค่อนข้างลำบาก
      ถ้ามันถูกจัดการให้อัตโนมัติแบบมองไม่เห็น ก็ทำพลาดได้ยาก แต่การทำให้เป็น black box ไม่ได้ช่วยมากนักต่อการกระจายความเข้าใจเชิงลึกว่า TLS ทำงานจริงอย่างไร
    • เหตุผลที่คนส่วนใหญ่เรียกว่า SSL น่าจะเป็นเพราะชื่อไลบรารีที่จัดการการสื่อสารปลอดภัยมีคำว่า SSL อยู่
      รวมถึง OpenSSL ที่ครองตลาดที่สุด และยังมี BoringSSL, LibreSSL, wolfSSL เป็นต้น
      ไลบรารีที่มี TLS อยู่ในชื่อก็มี GnuTLS, mbedTLS, s2n-tls, RustTLS แต่ใช้กันค่อนข้างน้อยกว่า
    • ปกติจะพูดว่า SSL
      เพราะมีโอกาสที่คนจะเข้าใจมากกว่า TLS ซึ่งถูกต้องกว่า และตอนนี้ก็ไม่มีใครใช้ SSL 3.0 จริง ๆ แล้ว
      ชื่อไลบรารีคลาสสิกอย่าง OpenSSL ก็มี SSL อยู่ด้วย
      แต่ก็อาจเป็นนิสัยจากสมัย Crypto Wars ในทศวรรษ 1990 ที่ได้เรียนรู้ SSL และถ้าจะใช้การเข้ารหัส SSL แบบจริงจังต้องไปหา Netscape เวอร์ชัน “US only” มาใช้
    • ปกติจะพูดว่า “https”
      เพราะบางครั้งคนทั่วไปก็รู้ความหมายของมัน
    • ช่วงนี้พูดว่า “TLS” มากขึ้นเรื่อย ๆ แต่จนถึงแค่ 1~2 ปีก่อนแทบจะพูดว่า “SSL” เสมอ
      ถึงอย่างนั้นบางครั้ง SSL ก็ยังหลุดออกมา
      อายุ 51 ปี และเริ่มทำงานด้าน IT กลางทศวรรษ 90

  • คิดว่า TLS 1.0 น่าจะมีการปรับปรุงจาก SSL 3.0 ค่อนข้างมากไม่ใช่หรือ
    ถ้าอ่านจากบทความอย่างเดียว ดูเหมือนแค่แก้ไม่กี่อย่างเพื่อให้ดูต่างกัน

    • ความแตกต่างหลักอยู่ที่ padding
      ตอนที่มีการเปิดเผยล่วงหน้าว่า POODLE attack มีผลเฉพาะกับ SSL3 และไม่มีผลกับ TLS1.0 แค่ข้อมูลนั้นก็ทำให้คาดเดาได้แล้วว่าน่าจะเป็น padding oracle
      ทั้งสองค่อนข้างคล้ายกัน และมองว่ามี “bug fix” บางอย่างเข้าไปก็น่าจะยุติธรรม
      เรื่องมันนานมากแล้ว อาจลืมบางอย่างไป หรือเพราะเคย implement SSL3 กับ TLS1.0 ควบคู่กันเสมอ เลยอาจพลาดรายละเอียดบางจุด
    • การเปลี่ยนแปลงมีน้อย และน้อยกว่าการปรับเวอร์ชันครั้งอื่นใด
      โดยรวมแล้วใกล้เคียงกับการที่ IETF ไม่ได้อนุมัติโพรโทคอล SSL 3.0 ตามเดิม แต่ทำเป็น ปักธงเขตอำนาจของตัวเอง มากกว่า
    • มีการเปลี่ยนแปลงและการปรับปรุงที่มีความหมายอย่างแน่นอน แต่ไม่ใช่การออกแบบใหม่ทั้งหมดแบบ SSL 3.0

  • บทความที่เกี่ยวข้องคือ “Randomness and the Netscape Browser” ใน Dr. Dobb's Journal เดือนมกราคม 1996
    https://people.eecs.berkeley.edu/~daw/papers/ddj-netscape.ht...
    เป็นบทความที่เขียนในปี 1996 แต่ภาษาที่ใช้รู้สึกต่างจากสิ่งพิมพ์ยุคปัจจุบันค่อนข้างมากแล้ว เลยทำให้รู้สึกแก่

    • ขึ้นอยู่กับว่าดูสิ่งพิมพ์ไหน
      เหมือนในปี 1996 งานเขียนอย่างบทความของ LWN [1] ในปัจจุบันก็อ่านได้ด้วยสำนวนที่ค่อนข้างคล้ายกัน
      เพียงแต่อาจมุ่งผู้อ่านทั่วไปมากขึ้นเล็กน้อย จึงแข็งน้อยลงนิดหน่อย
      [1] https://lwn.net/
    • ผู้เขียนบทความนั้นพบปัญหาด้านความปลอดภัยดังกล่าวและได้ขึ้น หน้าแรกของ New York Times ด้วย: https://www.nytimes.com/2012/02/15/technology/researchers-fi...

  • จำได้ว่าหนังสือ “SSL and TLS: Designing and Building Secure Systems” ของ Eric Rescorla มีประโยชน์มากในการทำความเข้าใจประวัติของ TLS และเส้นทางที่นำมาถึงปัจจุบัน
    เป็นหนังสือที่ออกในปี 2001 แต่ได้เตือนถึงปัญหาหลายอย่างที่ภายหลังกลายเป็น CVE แล้ว และยังหามือสองได้ในราคาไม่กี่ดอลลาร์

  • ราวปี 2014 คิดว่าฉันทามติว่า SSL 2.0 มีข้อบกพร่องร้ายแรง นั้นแน่นแฟ้นมากแล้ว
    แม้แต่ handshake ก็ยังไม่ได้รับการยืนยันตัวตนอย่างถูกต้อง