ปิดใช้งาน SSL สำรองและใช้เฉพาะ TLS สำหรับการเชื่อมต่อขาออกใน. NET หรือไม่ (พุดเดิ้ลบรรเทา)

ฉันพยายามที่จะลดช่องโหว่ของเราที่จะพุดเดิ้ล SSL 3.0 สำรองโจมตี ผู้ดูแลระบบของเราได้เริ่มปิดใช้งาน SSL แล้วเพื่อรองรับ TLS สำหรับการเชื่อมต่อขาเข้ากับเซิร์ฟเวอร์ของเรา และเรายังแนะนำให้ทีมของเราปิดการใช้งาน SSL ในเว็บเบราว์เซอร์ของพวกเขา ตอนนี้ผมกำลังมองหาที่ codebase .NET ของเราซึ่งประทับจิต HTTPS การเชื่อมต่อกับบริการต่างๆผ่านSystem.Net.HttpWebRequest ฉันเชื่อว่าการเชื่อมต่อเหล่านี้อาจเสี่ยงต่อการโจมตีของ MITM หากอนุญาตให้ใช้ทางเลือกจาก TLS เป็น SSL นี่คือสิ่งที่ฉันได้กำหนดไว้จนถึงตอนนี้ โปรดตรวจสอบอีกครั้งเพื่อยืนยันว่าฉันถูกต้องหรือไม่ ช่องโหว่นี้เป็นช่องโหว่ใหม่ดังนั้นฉันจึงยังไม่เห็นคำแนะนำใด ๆ จาก Microsoft เกี่ยวกับวิธีลดความเสี่ยงใน. NET:

1. โปรโตคอลที่อนุญาตสำหรับคลาส System.Net.Security.SslStream ซึ่งรองรับการสื่อสารที่ปลอดภัยใน. NET ถูกตั้งค่าทั่วโลกสำหรับแต่ละ AppDomain ผ่านคุณสมบัติSystem.Net.ServicePointManager.SecurityProtocol

2. ค่าเริ่มต้นของคุณสมบัตินี้ใน. NET 4.5 คือSsl3 | Tls(แม้ว่าฉันจะไม่พบเอกสารประกอบเพื่อสำรองข้อมูลนั้นก็ตาม) SecurityProtocolType เป็น enum ที่มีแอตทริบิวต์ Flags ดังนั้นจึงเป็นบิตหรือของทั้งสองค่า คุณสามารถตรวจสอบสิ่งนี้ในสภาพแวดล้อมของคุณด้วยรหัสบรรทัดนี้:

   Console.WriteLine (System.Net.ServicePointManager.SecurityProtocol ToString ());

3. ควรเปลี่ยนเป็นเพียงTlsหรือTls12ก่อนที่คุณจะเริ่มการเชื่อมต่อใด ๆ ในแอปของคุณ:

   System.Net.ServicePointManager.SecurityProtocol = System.Net.SecurityProtocolType.Tls;

4. สำคัญ:เนื่องจากคุณสมบัติรองรับแฟล็กระดับบิตหลายตัวฉันจึงถือว่า SslStream จะไม่ถอยกลับไปใช้โปรโตคอลอื่นที่ไม่ระบุโดยอัตโนมัติในระหว่างการจับมือ มิฉะนั้นอะไรจะเป็นจุดที่รองรับหลายแฟล็ก?

อัปเดต TLS 1.0 เทียบกับ 1.1 / 1.2:

ตามที่ Adam Langley ผู้เชี่ยวชาญด้านความปลอดภัยของ Google พบว่า TLS 1.0 มีความเสี่ยงต่อ POODLE ในภายหลังหากใช้ไม่ถูกต้องดังนั้นคุณควรพิจารณาย้ายไปที่ TLS 1.2 โดยเฉพาะ

การอัปเดตสำหรับ. NET Framework 4.7 ขึ้นไป:

ตามที่กล่าวถึงโดยProf Von Lemongargleด้านล่างเริ่มต้นด้วยเวอร์ชัน 4.7 ของ. NET Framework ไม่จำเป็นต้องใช้แฮ็คนี้เนื่องจากการตั้งค่าเริ่มต้นจะช่วยให้ระบบปฏิบัติการสามารถเลือกเวอร์ชันโปรโตคอล TLS ที่ปลอดภัยที่สุดได้ ดูแนวทางปฏิบัติที่ดีที่สุดของ Transport Layer Security (TLS) ด้วย. NET Frameworkสำหรับข้อมูลเพิ่มเติม

เรากำลังทำสิ่งเดียวกัน หากต้องการรองรับเฉพาะ TLS 1.2 และไม่มีโปรโตคอล SSL คุณสามารถทำได้:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

SecurityProtocolType.Tls เป็น TLS 1.0 เท่านั้นไม่ใช่ TLS ทุกเวอร์ชัน

ด้านข้าง: หากคุณต้องการตรวจสอบว่าไซต์ของคุณไม่อนุญาตให้มีการเชื่อมต่อ SSL คุณสามารถทำได้ที่นี่ (ฉันไม่คิดว่าสิ่งนี้จะได้รับผลกระทบจากการตั้งค่าข้างต้นเราต้องแก้ไขรีจิสทรีเพื่อบังคับให้ IIS ใช้ TLS สำหรับการเชื่อมต่อขาเข้า): https://www.ssllabs.com/ssltest/index.html

หากต้องการปิดใช้งาน SSL 2.0 และ 3.0 ใน IIS โปรดดูหน้านี้: https://www.sslshopper.com/article-how-to-disable-ssl-2.0-in-iis-7.html

คำตอบของ @Eddie Loeffen ดูเหมือนจะเป็นคำตอบที่ได้รับความนิยมมากที่สุดสำหรับคำถามนี้ แต่ก็มีผลเสียในระยะยาว หากคุณตรวจสอบหน้าเอกสารสำหรับ System.Net.ServicePointManager.SecurityProtocol ที่นี่ส่วนข้อสังเกตบอกเป็นนัยว่าขั้นตอนการเจรจาควรจัดการเรื่องนี้ (และการบังคับให้โปรโตคอลเป็นแนวทางปฏิบัติที่ไม่ดีเพราะในอนาคต TLS 1.2 จะถูกบุกรุกเช่นกัน) อย่างไรก็ตามเราจะไม่มองหาคำตอบนี้หากเป็นเช่นนั้น

จากการวิจัยพบว่าโปรโตคอลการเจรจา ALPN จำเป็นต้องเข้าถึง TLS1.2 ในขั้นตอนการเจรจา เราถือเอาสิ่งนั้นมาเป็นจุดเริ่มต้นและลองใช้. Net framework เวอร์ชันใหม่กว่าเพื่อดูว่าการสนับสนุนเริ่มต้นที่ใด เราพบว่า. Net 4.5.2 ไม่รองรับการต่อรองกับ TLS 1.2 แต่. Net 4.6 รองรับ

ดังนั้นแม้ว่าการบังคับ TLS1.2 จะทำให้งานเสร็จในตอนนี้ แต่ขอแนะนำให้คุณอัปเกรดเป็น. Net 4.6 แทน เนื่องจากนี่เป็นปัญหา PCI DSS สำหรับเดือนมิถุนายน 2559 หน้าต่างจึงสั้น แต่กรอบงานใหม่เป็นคำตอบที่ดีกว่า

UPDATE: จากความคิดเห็นฉันสร้างสิ่งนี้:

ServicePointManager.SecurityProtocol = 0;    
foreach (SecurityProtocolType protocol in SecurityProtocolType.GetValues(typeof(SecurityProtocolType)))
    {
        switch (protocol)
        {
            case SecurityProtocolType.Ssl3:
            case SecurityProtocolType.Tls:
            case SecurityProtocolType.Tls11:
                break;
            default:
                ServicePointManager.SecurityProtocol |= protocol;
            break;
        }
    }

ในการตรวจสอบความถูกต้องของแนวคิดนี้ฉันหรือใช้ SSL3 และ TLS1.2 ร่วมกันและรันโค้ดที่กำหนดเป้าหมายเซิร์ฟเวอร์ที่รองรับเฉพาะ TLS 1.0 และ TLS 1.2 (1.1 ถูกปิดใช้งาน) ด้วยโปรโตคอล or'd ดูเหมือนว่าจะเชื่อมต่อได้ดี ถ้าฉันเปลี่ยนเป็น SSL3 และ TLS 1.1 แสดงว่าเชื่อมต่อไม่สำเร็จ การตรวจสอบของฉันใช้ HttpWebRequest จาก System.Net และเรียกใช้ GetResponse () ตัวอย่างเช่นฉันลองแล้วและล้มเหลว:

        HttpWebRequest request = WebRequest.Create("https://www.contoso.com/my/web/resource") as HttpWebRequest;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls11;
        request.GetResponse();

ขณะนี้ได้ผล:

        HttpWebRequest request = WebRequest.Create("https://www.contoso.com/my/web/resource") as HttpWebRequest;
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls12;
        request.GetResponse();

สิ่งนี้มีข้อได้เปรียบเหนือการบังคับ TLS 1.2 ในกรณีนี้หากเฟรมเวิร์ก. Net ได้รับการอัพเกรดเพื่อให้มีรายการมากขึ้นใน Enum โค้ดจะได้รับการสนับสนุนตามที่เป็นอยู่ มีข้อเสียมากกว่าการใช้. Net 4.6 ใน 4.6 นั้นใช้ ALPN และควรรองรับโปรโตคอลใหม่หากไม่มีการระบุข้อ จำกัด

แก้ไข 4/29/2019 - Microsoft เผยแพร่บทความนี้เมื่อเดือนตุลาคมที่ผ่านมา มีบทสรุปที่ค่อนข้างดีของคำแนะนำของพวกเขาว่าควรทำอย่างไรใน. net framework เวอร์ชันต่างๆ

@ วัตสัน

ในรูปแบบ windows จะพร้อมใช้งานที่ด้านบนสุดของชั้นเรียน

  static void Main(string[] args)
    {
        ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
       //other stuff here
    }

เนื่องจาก windows เป็นเธรดเดียวจึงเป็นสิ่งที่คุณต้องการในกรณีที่เป็นบริการที่คุณต้องวางไว้เหนือการเรียกใช้บริการ (เนื่องจากไม่มีการบอกว่าคุณจะอยู่ในเธรดใด)

using System.Security.Principal 

ก็จำเป็นเช่นกัน

หากคุณสงสัยว่าโปรโตคอลใด. NET รองรับคุณสามารถลองใช้ HttpClient ได้ที่https://www.howsmyssl.com/

// set proxy if you need to
// WebRequest.DefaultWebProxy = new WebProxy("http://localhost:3128");

File.WriteAllText("howsmyssl-httpclient.html", new HttpClient().GetStringAsync("https://www.howsmyssl.com").Result);

// alternative using WebClient for older framework versions
// new WebClient().DownloadFile("https://www.howsmyssl.com/", "howsmyssl-webclient.html");

ผลลัพธ์คือการสาปแช่ง:

ลูกค้าของคุณใช้ TLS 1.0 ซึ่งเก่ามากอาจเสี่ยงต่อการโจมตีของ BEAST และไม่มีชุดการเข้ารหัสที่ดีที่สุด การเพิ่มเติมเช่น AES-GCM และ SHA256 เพื่อแทนที่ MD5-SHA-1 จะไม่สามารถใช้ได้กับไคลเอ็นต์ TLS 1.0 รวมถึงชุดการเข้ารหัสที่ทันสมัยอีกมากมาย

ดังที่ Eddie อธิบายไว้ข้างต้นคุณสามารถเปิดใช้งานโปรโตคอลที่ดีขึ้นได้ด้วยตนเอง:

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12 | SecurityProtocolType.Tls11; 

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

ฉันต้องใช้จำนวนเต็มเทียบเท่าเพื่อให้ได้ความจริงที่ว่าฉันยังคงใช้. NET 4.0

System.Net.ServicePointManager.SecurityProtocol = (SecurityProtocolType)3072;
/* Note the property type  
   [System.Flags]
   public enum SecurityProtocolType
   {
     Ssl3 = 48,
     Tls = 192,
     Tls11 = 768,
     Tls12 = 3072,
   } 
*/

ฉันพบวิธีแก้ปัญหาที่ง่ายที่สุดคือการเพิ่มรายการรีจิสตรีสองรายการดังนี้ (เรียกใช้สิ่งนี้ในพรอมต์คำสั่งด้วยสิทธิ์ของผู้ดูแลระบบ):

reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCrypto /t REG_DWORD /d 1 /reg:32

reg add HKLM\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 /v SchUseStrongCrypto /t REG_DWORD /d 1 /reg:64

รายการเหล่านี้ดูเหมือนจะส่งผลต่อวิธีที่. NET CLR เลือกโปรโตคอลเมื่อทำการเชื่อมต่อที่ปลอดภัยในฐานะไคลเอนต์

มีข้อมูลเพิ่มเติมเกี่ยวกับรายการรีจิสทรีนี้ที่นี่:

https://docs.microsoft.com/en-us/security-updates/SecurityAdvisories/2015/2960358#suggested-actions

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

หมายเหตุ : แม้ว่าตามบทความด้านบนนี้ควรปิดใช้งาน RC4 เท่านั้นและไม่มีใครคิดว่าสิ่งนี้จะเปลี่ยนแปลงไม่ว่าไคลเอ็นต์. NET จะได้รับอนุญาตให้ใช้ TLS1.2 + หรือไม่ด้วยเหตุผลบางประการก็มีสิ่งนี้ ผลกระทบ

หมายเหตุ : ตามที่ระบุไว้โดย @Jordan Rieger ในความคิดเห็นนี่ไม่ใช่วิธีแก้ปัญหาสำหรับ POODLE เนื่องจากไม่ได้ปิดใช้งานโปรโตคอลรุ่นเก่า - เพียงแค่อนุญาตให้ไคลเอนต์ทำงานกับโปรโตคอลที่ใหม่กว่าเช่นเมื่อเซิร์ฟเวอร์ที่ได้รับการแก้ไขปิดใช้งานรุ่นเก่า โปรโตคอล อย่างไรก็ตามด้วยการโจมตี MITM เห็นได้ชัดว่าเซิร์ฟเวอร์ที่ถูกบุกรุกจะเสนอโปรโตคอลที่เก่ากว่าให้กับลูกค้าซึ่งลูกค้าจะใช้อย่างมีความสุข

สิ่งที่ต้องทำ : พยายามปิดการใช้งาน TLS1.0 และ TLS1.1 ฝั่งไคลเอ็นต์ด้วยรายการรีจิสทรีเหล่านี้ แต่ฉันไม่รู้ว่าไลบรารีไคลเอ็นต์. NET http เคารพการตั้งค่าเหล่านี้หรือไม่:

https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings#tls-10

https://docs.microsoft.com/en-us/windows-server/security/tls/tls-registry-settings#tls-11