โครงการ OpenSSL ไลบรารีพื้นฐานสำหรับเข้ารหัสเพื่อสื่อสารตามโปรโตคอล SSL/TLS ประกาศหยุดซัพพอร์ต (End of Life) เวอร์ชัน 1.1.1 ซึ่งถือเป็นการสิ้นสุดของสาย OpenSSL 1.x

OpenSSL 1.1.1 เป็นเวอร์ชันซัพพอร์ตระยะยาว (LTS) ที่ออกมาตั้งแต่ปี 2018 มีระยะเวลาซัพพอร์ตนาน 5 ปีเต็ม ตอนนี้สิ้นสุดแล้วตามแผนการที่ประกาศไว้เมื่อ 5 ปีก่อน

ผู้ใช้งานจำเป็นต้องอัพเกรดไปใช้ OpenSSL 3.x โดยมีทางเลือก 2 ทางคือ

• OpenSSL 3.0 LTS ซัพพอร์ตถึงเดือนกันยายน 2026
• OpenSSL 3.1 ซัพพอร์ตถึงเดือนมีนาคม 2025

ที่มา - OpenSSL via The Register

ปัจจุบันผู้ใช้ Cloudflare ทุกคนจะได้รับใบรับรองการเข้ารหัสเว็บ (SSL Certificate) ฟรีอัตโนมัติ โดยจะออกเป็นใบรับรองแบบ wildcard เช่น *.example.com แต่ก็มีผู้ใช้บางส่วนที่มี subdomain ซ้อนกันสองระดับขึ้นไป เช่น a.b.example.com หรือ a.b.c.example.com ซึ่งใบรับรองแบบฟรีไม่รองรับ

หากต้องการออกใบรับรองดังกล่าว ผู้ใช้ต้องเสียเงินสมัคร Advanced Certificate Manager (ACM) เดือนละ 10 ดอลลาร์สหรัฐ ที่สามารถออกใบรับรองให้ subdomain ได้ 50 ชื่อ แต่ก็มีข้อจำกัดว่าแอดมินต้องระบุชื่อทีละชื่อ ซึ่งไม่สะดวกและเสี่ยงต่อความผิดพลาด

โครงการ Chromium ที่เป็นฐานของเบราว์เซอร์ Chrome ประกาศโครงการ Chrome Root Program และ Chrome Root Store เพื่อจัดการฐานข้อมูล root CA ที่สามารถออกใบรับรองเข้ารหัสแบบต่างๆ ได้

ที่ผ่านมา Chromium/Chrome ใช้ฐานข้อมูล root CA ของแพลตฟอร์มเป็นหลัก ทำให้ประสบการณ์ใช้งานต่างกันในแต่ละแพลตฟอร์ม เช่น บนระบบปฎิบัติการรุ่นเก่าๆ ก็อาจจะไม่สามารถเข้าเว็บที่ใบรับรองจาก root CA ใหม่ๆ ได้แม้จะใช้ Chrome รุ่นใหม่ก็ตาม อย่างไรก็ดี แม้จะใช้ฐานข้อมูลของระบบปฎิบัติการแต่ที่ผ่านมา Chrome ก็มีนโยบายเพิ่มเติมไม่ยอมรับ root CA บางรายอยู่แล้ว เช่น เหตุการณ์ถอดถอน root CA ของ Synmantec การมีโครงการ root CA ของตัวเองจะทำให้ตัวเบราว์เซอร์ควบคุมได้มากขึ้น

ผู้ใช้ Apache Web Server คงคุ้นเคยกับ mod_ssl ที่ใช้จัดการ HTTPS โดยโมดูลนี้เขียนด้วยภาษา C ซึ่งมีปัญหาตามมาเรื่องความปลอดภัยที่ระดับตัวภาษา และที่ผ่านมาก็พบช่องโหว่ความปลอดภัยมากมาย

ล่าสุด กูเกิลประกาศสนับสนุนโครงการใหม่ mod_tls ที่ทำงานแบบเดียวกัน แต่เขียนด้วยภาษา Rust ที่ออกแบบมาให้ปลอดภัยมากขึ้น (memory safety)

โมดูล mod_tls จะรันอยู่บนไลบรารี Rustls ที่สร้างขึ้นมาทดแทน OpenSSL ซึ่งเป็นภาษา C เช่นกัน หน่วยงานที่พัฒนาคือ Internet Security Research Group (ISRG) ที่เรารู้จักจากโครงการ Let's Encrypt จะรับเงินสปอนเซอร์จากกูเกิล ไปจ้าง Stefan Eissing หนึ่งในนักพัฒนา Apache Web Server มานำทีม

ทีมงาน Chromium ประกาศว่า Chrome 77 จะเลิกแสดงแถบ SSL EV ที่เคยแสดงชื่อองค์กรผู้ขอใบรับรองแบบ Extended Validation (EV) แล้วจะนำข้อมูลนี้ไปแสดงเมื่อผู้ใช้กดไอคอนกุญแจเพื่อขอดูข้อมูลเว็บไซต์แทน ทำให้หลังจากนี้เว็บธนาคารจำนวนมาก ที่มักแสดงชื่อธนาคารบนแถบ URL จะเหลือเพียงโดเมนอย่างเดียว

Chrome มีแนวทางลดความสำคัญของใบรับรองแบบ EV เรื่อยมา จากแต่เดิมแถบ EV เคยเป็นสีเขียวเด่นก็กลายเป็นสีเดียวกับโดเมน ส่วน iOS และ macOS นั้นเลิกแสดงไปก่อนหน้านี้แล้ว

มาตรฐาน TLS 1.3 แก้ไขมานานและผ่านโหวตไปตั้งแต่เดือนมีนาคมที่ผ่านมา ตอนนี้ก็ได้เลข RFC เป็นทางการคือ RFC8446 นับเป็นเวลาสิบปีพอดีหลังจาก TLS 1.2 หรือ RFC5246

แม้ว่าตัวมาตรฐานจะเพิ่งออกเป็นทางการ แต่ในความปฎิบัติไลบรารีจำนวนมากรองรับฟีเจอร์ต่างๆ ของ TLS 1.3 อยู่ก่อนแล้ว เช่น Chrome นั้นรองรับมาตั้งแต่ Chrome 56 และเปิดใช้งานเป็นค่าเริ่มต้นมาตั้งแต่ Chrome 63

หลังจาก Blognone เคยนำเสนอรายงานสำรวจการเปิดใช้งาน HTTPS ในไทย ประจำปีปี 2016 ไป ขณะนี้ผ่านมาหนึ่งปีกว่าๆ แล้ว ก็สมควรถึงเวลาที่จะสำรวจติดตามผลกันอีกครั้ง

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

GoDaddy แจ้งว่าการอัพเกรดซอฟต์แวร์เพื่อตรวจสอบโดเมนเมื่อปีที่แล้วมีช่องโหว่ ทำให้กระบวนการออกใบรับรองไม่เป็นไปตามมาตรฐานของ CA/Browser Forum และทางบริษัทจะยกเลิกใบรับรอง 8,850 ใบ กระทบลูกค้ารวม 6,100 ราย

ช่องโหว่เป็นซอฟต์แวร์ยืนยันความเป็นเจ้าของโดเมนด้วยการวางไฟล์เปล่าตามชื่อที่กำหนดเอาไว้ในเว็บเซิร์ฟเวอร์ โดยระบบตรวจสอบนี้จะหาว่าเว็บเซิร์ฟเวอร์ตอบไฟล์กลับมาหรือไม่ แต่การอัพเดตซอฟต์แวร์กลับทำให้ระบบตรวจสอบไม่ตรวจ status code ที่เซิร์ฟเวอร์ตอบกลับมา ทำให้เมื่อเซิร์ฟเวอร์ไม่พบไฟล์แล้วตอบกลับมาเป็นรหัส 404 แต่ยังคงมีชื่อไฟล์ในเนื้อ HTTP ทาง GoDaddy ก็ยอมปล่อยใบรับรองให้กับเซิร์ฟเวอร์เหล่านั้น โดยทางบริษัทระบุว่ายังไม่พบการใช้ช่องโหว่นี้จงใจหลอกเพื่อเอาใบรับรองแต่อย่างใด

ไมโครซอฟท์ประกาศจะเริ่มแจ้งเตือนเว็บไซต์ที่ใช้ใบรับรอง SHA-1 ในวันที่ 14 กุมภาพันธ์ 2017 ซึ่งจะมีผลทั้งบนเบราว์เซอร์ Microsoft Edge และ Internet Explorer 11 แต่ในส่วนของผู้ใช้ยังคงมีตัวเลือกในการเข้าชมหน้าเว็บได้อยู่

ใบรับรอง SHA-1 ที่ได้รับผลกระทบคือ ใบรับรองที่เกี่ยวข้อง (chain to) กับ Microsoft Trusted Root CA เท่านั้น แต่ทั้งนี้ไมโครซอฟท์ก็ยังแนะนำให้รีบย้ายไปใช้ใบรับรอง SHA-256 แทน

ที่มา - Microsoft Edge Developer

บทความที่เกียวข้อง: เตรียมลา SHA-1 ตอบคำถามทำไมเข้ารหัสยุ่งยากแล้วต้องอัพเดตใหม่

ไลบรารี SSL กลายเป็นจุดโจมตีสำคัญนับแต่ช่องโหว่ Heartbleed เป็นต้นมา ก็มีความพยายามแยกสายการพัฒนาออกมาเป็น LibreSSL โดยทีมงาน OpenBSD หรือ BoringSSL ของกูเกิล ตอนนี้มีโครงการใหม่ในชื่อ BearSSL

BearSSL มีนักพัฒนาหลักคือ Thomas Pornin โปรแกรมเมอร์ด้านวิทยาการเข้ารหัสลับ (เขาเป็นผู้ใช้ระดับ top 0.03% ของ Security StackExchange) โดยมีแนวทางคือการรักษาความเรียบง่ายเพื่อให้มีความปลอดภัยสูงสุด ฟีเจอร์หลักๆ เช่น

หลังจาก Chrome เตรียมจะแจ้งเตือนผู้ใช้ว่ากำลังเข้าเว็บที่รับรองโดย CA ที่ติดตั้งเองในเครื่อง ทางทีมแอนดรอยด์ก็ออกมาแจ้งเตือนผู้ใช้ว่า Android 7.0 Nougat จะบังคับเรื่อง CA ในเครื่องมากกว่าเดิม คือค่าเริ่มต้นจะไม่ยอมรับ CA ที่ติดตั้งเองในเครื่องอีกแล้ว แต่ยังมีผลเฉพาะแอปที่ตั้ง API level 24 (Nougat) เท่านั้น

การติดตั้ง CA ในเครื่องลูกข่ายหลายครั้งจำเป็นสำหรับการพัฒนาแอป หรือแอปบางส่วนก็ต้องการยอมตามนโยบายองค์กรที่เปิดให้แอปถูกดักฟังโดยระบบขององค์กรได้ กรณีเช่นนี้บน Android Nougat นักพัฒนาจำเป็นต้องยอมรับอย่างชัดเจน โดยสามารถคอนฟิกได้อย่างละเอียด เช่น ยอมรับ CA ที่ติดตั้งเองในบางโดเมน, ยอมรับ CA เฉพาะใบสำหรับการดีบั๊ก

มาตรฐาน Certificate Transparency (CT) ที่เริ่มต้นโดยกูเกิล เรียกร้องให้หน่วยงานออกใบรับรองดิจิตอล (CA) ทุกราย รายงานการออก CA ทุกใบ แต่การเปิดเผยข้อมูลเช่นนี้ทำให้ทุกคนรู้ว่า CA มีลูกค้ามากน้อยแค่ไหนทำให้ CA ส่วนมากมักจะยอมเปิด CT เฉพาะการออกใบรับรองแบบ Extended Validation (EV) เท่านั้น ยกเว้น CA ที่ออกใบรับรองฟรีอย่าง Let's Encrypt แต่ตอนนี้ WoSign ที่เป็น CA สัญชาติจีนก็ออกมาประกาศว่าจะส่งข้อมูล CT สู่สาธารณะเมื่อออกใบรับรองทุกใบแล้ว

ยุคก่อนที่จะมี Let's Encrypt ที่ให้บริการใบรับรองเข้ารหัสฟรี StartCom เคยให้บริการใบรับรองฟรีมาก่อนแล้วในชื่อ StartSSL แม้จะมีกระบวนการค่อนข้างยุ่งยากสักหน่อยก็ตาม ตอนนี้ทาง StartCom ก็มาเปิดบริการแข่งกับ Let's Encrypt ในชื่อ StartEncrypt

StartEncrypt จะมีไคลเอนต์บนเครื่องที่ต้องการขอใบรับรอง โดยไม่ได้ใช้โปรโตคอล ACME ที่ออกแบบมาเพื่อการขอใบรับรองดิจิตอลอัตโนมัติจาก Let's Encrypt แต่ใช้โปรโตคอลของตัวเอง จุดต่างสำคัญคือการออกใบรับรองทีละ 1 ปีเช่นเดียวกับ StartSSL เดิม เป็นจุดที่หลายคนอาจจะไม่ชอบ Let's Encrypt ที่ออกใบรับรองครั้งละเพียง 90 วันเท่านั้น

ทีมวิจัยรายงานการโจมตี DROWN ที่สามารถถอดรหัสการเชื่อมต่อ TLS รุ่นใหม่ๆ (ทดสอบใน TLS 1.2) ได้สำเร็จ โดยกระบวนการนี้แม้จะอันตรายมากแต่ก็มีเงื่อนไขหลายอย่าง ได้แก่

ปี 2016 เป็นปีสำคัญสำหรับความเปลี่ยนแปลงด้านความปลอดภัยของความปลอดภัยของเว็บ เพราะเป็นปีที่ใบรับรองดิจิทัล Let's Encrypt เริ่มให้บริการฟรีตั้งแต่ต้นปี พร้อมทั้งฝั่งโฮสติงที่ทยอยรองรับเพิ่มขึ้นเรื่อยๆ ปีนี้เราจึงมาสำรวจกันว่าเว็บใดใช้การรองรับแบบใดกันแล้วบ้าง

รูปแบบการรองรับ HTTPS

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

โครงการใบรับรองดิจิตอลฟรี Let's Encrypt เพิ่งเปิดให้บริการต่อสาธารณะไม่กี่วัน กลุ่มอำนาจเก่าผู้เสียผลประโยชน์ อย่าง GoDaddy และ Namecheap ก็ออกมาเคลื่อนไหว

ฝั่ง Namecheap นั้นออกมาเขียนบล็อกโจมตี ระบุข้อเสียของใบรับรองดิจิตอลฟรี ระบุว่าใบรับรองฟรีนั้นเพียงแค่เพิ่มการเข้ารหัสท่านั้น และไม่ได้ตรวจสอบผู้รับใบรับรองก่อนที่จะมอบใบรับรอง (ซึ่งไม่จริง เพราะ Let's Encrypt นั้นตรวจสอบผู้ถือครองโดเมน)

ขณะที่ GoDaddy ก็ออกหน้าเปรียบเทียบใบรับรอง และระบุว่าการทำเว็บเพื่อการค้านั้นต้องใช้ใบรับรองแบบ Extended Validation เท่านั้น

ประเด็นการยกเลิกรองรับใบรับรองดิจิตอลที่ตรวจสอบด้วย SHA-1 นับเป็นการย้ายมาตรฐานความปลอดภัยขนานใหญ่ที่สุดครั้งหนึ่งของโลกอินเทอร์เน็ต ภายในปีหน้าเว็บต่างๆ ทั่วโลกจะถูกกดดันให้ต้องรองรับ SHA-2 เช่น SHA-256 ขึ้นไปเท่านั้น ไม่เช่นนั้นเว็บเบราว์เซอร์จะเริ่มเตือนว่าไม่ปลอดภัยโดยไม่มีทางออกอื่น (ตอนนี้ยังมีทางออกเช่นขอใบรับรองที่อายุสั้นๆ ได้)

แต่ Alex Stamos จากเฟซบุ๊ก และ CloudFlare ก็ออกมาชี้ปัญหาที่กำลังจะเกิดขึ้นในอีกไม่กี่วันข้างหน้านี้ ว่าเว็บขนาดใหญ่ยังมีปัญหาเพราะผู้ใช้จำนวนถึง 3-7% ในแต่ละประเทศยังใช้เบราว์เซอร์ที่ไม่รองรับ SHA-2 อยู่

Let's Encrypt เปิดตัวโครงการมาครบรอบหนึ่งปีพอดี กำหนดการเดิมที่จะปล่อยใบรับรองให้กับสาธารณะวันจันทร์นี้ก็เลื่อนไปเป็นวันที่ 3 ธันวาคมที่จะถึงนี้ แม้จะเปิดให้คนทั่วไปใช้งาน แต่ทางโครงการก็ยังระบุว่าเป็นช่วงทดสอบระบบ (เบต้า) เท่านั้น และยังมีงานต้องทำก่อนจะพร้อมใช้งานจริงสำหรับคนทั่วไป

จนตอนนี้ทาง Let's Encrypt ปล่อยใบรับรองให้กับผู้ที่เข้าร่วมโครงการเบต้าแล้วกว่า 11,000 ใบ

ที่มา - Let's Encrypt

กูเกิลออกมาเผยสถิติเรื่องการเข้ารหัสการส่งอีเมลผ่าน TLS เพื่อป้องกันการดักข้อมูลระหว่างทาง

• รอบสองปีที่ผ่านมา (2013-2015) อีเมลที่ส่งเข้าหา Gmail และถูกเข้ารหัส เพิ่มสัดส่วนจาก 33% เป็น 61%
• ในช่วงเวลาเดียวกัน อีเมลที่ถูกส่งจาก Gmail และเข้ารหัส เพิ่มจาก 60% เป็น 80% (Gmail จะเลือกเข้ารหัสเมื่อโฮสต์ปลายทางรองรับการเข้ารหัส แปลว่าโฮสต์ที่รองรับเพิ่มจำนวนมากขึ้น)
• ตอนนี้ 94% ของอีเมลขาเข้า Gmail มีระบบตรวจสอบตัวตนผู้ส่ง เพื่อป้องกันปัญหา phishing หรือปลอมตัวแล้ว

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

ทีมวิจัย WeakDH ที่เคยเปิดเผยช่องโหว่ Logjam ตีพิมพ์รายงานวิจัย ประเมินค่าใช้จ่ายในการเจาะกระบวนการแลกกุญแจ Diffie-Hellman (DH) ที่ขนาด 1024 บิตแล้วพบว่าค่าใช้จ่ายในการเจาะระบบเข้ารหัสนี้น่าจะง่ายพอที่ NSA จะเจาะการเข้ารหัส และเอกสารของ Edward Snowden ที่หลุดออกมาชี้นำให้เห็นว่า NSA อาจจะใช้กระบวนการนี้ในการเจาะการเชื่อมต่อเข้ารหัสสำคัญๆ หลายจุด

ทีมวิจัยร่วมกันสามชาติ เนเธอร์แลนด์, ฝรั่งเศส, และสิงคโปร์ แถลงผลงานวิจัยการสร้างค่าที่มีค่าแฮช SHA1 ตรงกัน (SHA1 collision) ด้วยต้นทุนเพียง 75,000 ถึง 120,000 ดอลลาร์หากเช่าเครื่องจาก Amazon EC2 จากเดิมที่ Bruce Schneier เคยประมาณการณ์ว่าปี 2015 จะใช้ทุนประมาณ 700,000 ดอลลาร์

งานวิจัยนี้แสดงความง่ายของการสร้างข้อมูลที่มีค่าแฮชตรงกัน จากฟังก์ชั่น SHA1 compression function โดยคลัสเตอร์ของทีมวิจัยสามารถปลอมค่าแฮชจากฟังก์ชั่นนี้ได้ในเวลาเพียง 10 วัน แม้ว่าจะไม่ได้แสดงการปลอม SHA1 โดยตรง แต่ทีมงานวิจัยก็ระบุว่ากระบวนการปลอมค่าจากฟังก์ชั่นที่นำเสนอแสดงให้เห็นว่าเป็นไปได้ที่จะปลอมค่า SHA1 โดยตรงด้วยต้นทุนที่ต่ำกว่าที่เคยคาดกันมาก

การเข้ารหัสแบบ RC4 มีความปลอดภัยต่ำ เพราะกระบวนการสุ่มเลขไม่ดีเท่าที่ควร ซึ่งในแวดวงความปลอดภัยเองก็เตรียมถอด RC4 ออกจากมาตรฐาน IETF มาได้สักพักแล้ว

วันนี้ผู้พัฒนาเบราว์เซอร์รายใหญ่ 3 ค่ายคือ Google, Microsoft, Mozilla ออกมาประกาศแผนว่าจะถอดการใช้งาน RC4 ออกจากเบราว์เซอร์ของตัวเอง (Chrome, IE, Edge, Firefox) พร้อมกันในช่วงต้นปี 2016

การถอด RC4 ไม่ส่งผลกระทบต่อผู้ใช้ทั่วไปมากนัก เพราะปัจจุบันเราใช้การเชื่อมต่อปลอดภัย HTTPS ผ่านโพรโทคอล TLS 1.2 ในขณะที่ RC4 จะถูกใช้ต่อเมื่อเซิร์ฟเวอร์ไม่รองรับ TLS 1.2 หรือ 1.1 และถอยกลับ (fallback) มาเชื่อมต่อผ่าน TLS 1.0 แทน

อเมซอนเปิดตัวไลบรารี TLS ของตัวเองในชื่อ s2n โดยเน้นความเล็กและเร็ว จุดเด่นสำคัญที่สุดคือโค้ดที่สั้นกว่า OpenSSL อย่างมาก โดยโค้ดในส่วน TLS นั้น s2n มีโค้ด 6,000 บรรทัด เทียบกับ OpenSSL ที่มีโค้ด 70,000 บรรทัด

วันนี้ (14 มิถุนายน 2558) ผู้ใช้ Outlook.com (ชื่อเดิมคือ Hotmail) หลายรายพบปัญหาล็อกอินเข้าหน้าเว็บไซต์แล้วปรากฏข้อความแจ้งเตือนใบรับรอง SSL ไม่ถูกต้อง จากการตรวจสอบเบื้องต้นพบว่าเซิร์ฟเวอร์ของ Outlook.com ส่งใบรับรอง SSL ของ bing.com มาให้ แทนที่จะเป็น login.live.com หรือ mail.live.com ตามที่ควรจะเป็น (ภาพประกอบท้ายข่าว)

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

ข้อแนะนำสำหรับผู้ที่พบปัญหานี้คือไม่ควรล็อกอินเข้า Outlook.com จนกว่า Microsoft จะแก้ปัญหาเสร็จ

ส่วนประกอบที่สำคัญสำหรับ SSL นั้นมีสองส่วนหลักๆ คือ กุญแจสาธารณะ และลายเซ็นดิจิทัล ซึ่งในปัจจุบันนิยมใช้ค่าแฮชของ SHA-1 มาเข้ารหัสด้วยกุญแจ RSA จาก CA (Certificate Authority) จึงจะได้ลายเซ็นดิจิทัลออกมา

หลังจากที่ Google ประกาศนโยบายให้ SHA-1 ไม่ปลอดภัยตั้งแต่ต้นปี 2015 เป็นต้นไป

รวมถึงข่าวเก่าได้ระบุว่า SHA-1 นั้น เริ่มไม่ปลอดภัยมากขึ้นตามเทคโนโลยีที่ก้าวกระโดด