เหตุใด SSL / TLS จึงไม่รวมอยู่ในระบบปฏิบัติการสมัยใหม่

16

โปรโตคอลเครือข่ายพื้นฐานจำนวนมากที่ประกอบขึ้นเป็นโครงสร้างพื้นฐานของอินเทอร์เน็ตถูกสร้างขึ้นในระบบปฏิบัติการส่วนใหญ่ ตัวอย่างเช่น TCP, UDP และ DNS ทั้งหมดมีอยู่ใน Linux, UNIX และ Windows และให้บริการแก่โปรแกรมเมอร์ผ่าน API ระบบระดับต่ำ

แต่เมื่อพูดถึง SSL หรือ TLS เราต้องเปลี่ยนไปใช้ห้องสมุดบุคคลที่สามเช่น OpenSSL หรือ Mozilla NSS

SSL เป็นโปรโตคอลที่ค่อนข้างเก่าและโดยทั่วไปจะเป็นมาตรฐานอุตสาหกรรมที่แพร่หลายเหมือนกับ TCP / IP ดังนั้นทำไมมันไม่สร้างในระบบปฏิบัติการส่วนใหญ่

— Channel72
แหล่งที่มา

5

อะไรคือความแตกต่างในทางปฏิบัติระหว่าง 'ในตัว' และ 'รวมกับ'? เท่าที่ฉันรู้ระบบปฏิบัติการทั้งหมดมาพร้อมกับการใช้งานรวมของ SSL / TLS

— zneak

ข้อแตกต่างคือ TCP และ DNS ถูกนำไปใช้ในโค้ดเคอร์เนล แต่ SSL มีให้บริการผ่านห้องสมุดบุคคลที่สามเท่านั้น ในขณะที่มักจะเป็นเรื่องเล็กน้อยในการติดตั้งการสนับสนุน SSL และระบบปฏิบัติการจำนวนมากยังมาพร้อมกับนอกระบบ แต่ก็ยังมีข้อเสียในทางปฏิบัติ: ตัวอย่างเช่นถ้าฉันเขียนไลบรารีที่ใช้การใช้งาน SSL เฉพาะ (เช่น OpenSSL, NSS, GnuTLS และอื่น ๆ ) ซอฟต์แวร์ของฉันตอนนี้มีการพึ่งพาซึ่งผู้ใช้ต้องจัดการ นี่จะไม่ใช่ปัญหาหาก SSL ถูกสร้างขึ้นในระบบปฏิบัติการ ฉันหมายความว่ามันไม่เหมือนฉันกังวลว่าผู้ใช้ของฉันจะต้องติดตั้งการสนับสนุนสำหรับ TCP

— Channel72

3

ฉันไม่คิดว่าการมี SSL ในตัวจะช่วยแก้ปัญหาที่คุณพูดถึง ตอนนี้แทนที่จะขึ้นอยู่กับไลบรารีเฉพาะคุณจะขึ้นอยู่กับระบบปฏิบัติการเฉพาะ

— zneak

1

ทำไมไม่มี jpeg libraries? คำถามเดียวกันที่มีประสิทธิภาพ คุณกำลังดูตำแหน่งที่ผิดของสแต็ก ระบบปฏิบัติการที่ทันสมัยทั้งหมดมีบางสิ่งที่รวมมาเพื่อรองรับ SSL (MSFT มี .NET SDK, Linux / Solaris มีพวง + มีคนอื่น ๆ )

— iivel

3

คุณต้องการมันในเคอร์เนลหรือไม่? ดูเหมือนฉันจะแออัดมากแล้ว

— Matthieu M.

9

ฉันคิดว่าส่วนใหญ่ขึ้นอยู่กับสิ่งที่คุณเห็นว่า "ระบบปฏิบัติการ" ถ้าเป็นเคอร์เนลคำตอบของฉันจะเป็น: ทำไมมันควร? ฉันอาจจะผิด แต่ DNS ไม่ได้เป็นส่วนหนึ่งของ glibc บนระบบ Linux ซึ่งเป็นห้องสมุดของบุคคลที่สาม

หากไม่เกี่ยวกับเคอร์เนลหรือพื้นที่ผู้ใช้เกือบทุก OS / แพลตฟอร์มมีสแต็ก SSL / TLS บางคนอาจมีมากกว่าหนึ่ง

มันสามารถถูกมองว่าเป็นข้อได้เปรียบ หากไม่มี OpenSSL คุณจะต้องปรับให้เข้ากับ API Windows, Mac และ Linux (และ ... ) TLS ที่ไม่รวมส่วนหนึ่งของระบบปฏิบัติการอนุญาตให้เขียนแอปพลิเคชัน TLS ข้ามแพลตฟอร์มได้ เพียงเลือกไลบรารี TLS ที่รองรับแพลตฟอร์มเป้าหมายของคุณ

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

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

— paztulio
แหล่งที่มา

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

— zneak

1

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

— paztulio

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

— zneak

7

มีปัญหาทางกฎหมาย บางประเทศมีการเข้ารหัสในกลุ่มเดียวกันกับอาวุธ การใส่รหัสการเข้ารหัสในเคอร์เนลทำให้การส่งออกของรหัสเคอร์เนลยากขึ้น

— dan_waterworth
แหล่งที่มา

2

มีประโยชน์ชัดเจนในการสร้าง TCP ลงในระบบปฏิบัติการ TCP ต้องการเวลาที่แม่นยำและการตอบสนองอย่างรวดเร็วต่อแพ็คเก็ตเครือข่ายแม้ว่าจะไม่มีข้อมูลแอปพลิเคชันเข้ามาเกี่ยวข้อง หากคุณพยายามใช้ TCP ในพื้นที่ผู้ใช้ด้านบนของ IP API ทั่วไปมันจะแย่กว่านั้นมาก ไม่มีข้อได้เปรียบที่คล้ายคลึงกันในการรวม SSL ในเคอร์เนล

ในทางกลับกันมีข้อเสียเล็กน้อย ตัวอย่างเช่น SSL ต้องการจัดการคีย์ริงและรายการใบรับรองและสิ่งที่คล้ายกัน การทำเช่นนั้นผ่านเคอร์เนลหรือ OS API จะไม่เหมาะสม ดังนั้นแม้ว่ามันจะมาพร้อมกับระบบปฏิบัติการมันก็จะเป็นห้องสมุด (เหมือนใน Windows) ห้องสมุดเหล่านั้นมีอยู่แล้วดังนั้นในที่สุดมันก็แค่เปลี่ยนบรรจุภัณฑ์

— เดวิดชวาร์ตษ์
แหล่งที่มา

1

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

นักพัฒนาระบบปฏิบัติการไม่แตกต่างกันมาก บางครั้งมีตัวอย่างที่น่าสนใจ - ตัวอย่างเช่นรูปแบบธุรกิจหรือนักกฎหมายของคุณกำหนดให้คุณต้องปิดรหัส - ดังนั้นคุณจึงไม่มีทางเลือกมากนักในเรื่อง: ถ้าคุณไม่สามารถหาคนที่จะให้คุณทำ สิ่งที่คุณต้องทำจากนั้นคุณต้องม้วนตัวเอง คนอื่น ๆ ได้กล่าวแล้วว่า Microsoft ทำเช่นนี้ได้อย่างไร แต่โดยทั่วไปนักพัฒนาระบบปฏิบัติการที่สามารถใช้ไลบรารีบุคคลที่สามต้องการทำเช่นนั้นด้วยเหตุผลเดียวกับที่นักพัฒนาแอปพลิเคชันทำ

— The Spooniest
แหล่งที่มา

0

ฉันเป็นนักพัฒนา windows ดังนั้นฉันจึงไม่สามารถพูดกับระบบปฏิบัติการอื่น ๆ ได้ แต่บน Windows พวกเขามี SSL ในตัวเป็นเวลานาน พวกเขาเรียกมันว่าSChannelและในขณะที่มันรองรับมันเป็นหนึ่งใน API ที่มีความลับมากกว่าที่ใคร ๆ ก็จะต้องคิดออก

— DXM
แหล่งที่มา

0

SSL เป็นเลเยอร์เหนือโปรโตคอลระดับล่าง ตัวอย่างเช่น SSL รันบนด้านบนของ TCP (ซึ่งอยู่เหนือส่วนบนของ IP)

ระบบปฏิบัติการหยุดอยู่ที่ใด

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

มันไม่น่าเป็นไปได้เลยที่ SSL ในเคอร์เนลจะนำไปสู่ประสิทธิภาพที่เพิ่มขึ้นอย่างมาก

เคอร์เนลระบบปฏิบัติการที่ทันสมัยทำงานได้หลายล้านบรรทัดเพิ่มมากขึ้นเพียงเพิ่มความซับซ้อนและเวลาในการดีบั๊กมากขึ้น การปล่อยสิ่งต่าง ๆ เช่นเลเยอร์โปรโตคอลที่สูงกว่าออกจากระบบปฏิบัติการทำให้การพัฒนาระบบปฏิบัติการง่ายขึ้นและในที่สุดก็สร้างความแตกต่างให้กับฟังก์ชั่นหรือประสิทธิภาพของแอพพลิเคชั่นปลายทาง (มันอาจทำให้นักพัฒนาทำงานสำหรับแอพพลิเคชั่นสุดท้ายได้เจ็บปวดขึ้นอีกเล็กน้อย)

— quickly_now
แหล่งที่มา

0

มีเคอร์เนลที่รองรับ Crypto และ SSL สิ่งนี้สมเหตุสมผลเนื่องจากเคอร์เนลสามารถเชื่อมต่อกับฮาร์ดแวร์ได้อย่างมีประสิทธิภาพยิ่งขึ้นและยังมั่นใจในการปกป้องข้อมูลรับรองจากแอปพลิเคชันใด ๆ ตัวอย่างที่ดีคือ kssl, Kernel-reverse-SSL Proxy proxy ใน Solaris หรือไลบรารี crypto ต่าง ๆ ในเคอร์เนล (ใช้สำหรับ VPNs) เอ็นจิ้นเข้ารหัสลับเร่งความเร็วฮาร์ดแวร์ทั่วไปยังมีโมดูลเคอร์เนล (และสามารถเข้าถึงได้ผ่าน PKCS # 11 หรืออินเตอร์เฟสเข้ารหัสลับเฉพาะ OS)

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

— Eckes
แหล่งที่มา