ทำเว็บไซต์ให้ปลอดภัยขึ้นอีกนิดนึง ไม่ยากเกินไป ถ้าเขียนเว็บได้ก็น่าจะทำได้ #websecurity

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

เครื่องมือตรวจสอบเบื้องต้น (ส่วนใหญ่ฟรี)

ใครเป็นคนดูแลเว็บ ลองใช้เครื่องมือในลิงก์นี้ตรวจสอบเบื้องต้นก่อนก็ได้ครับ ว่าเว็บไซต์เรายังโอเคไหม: 12 Online Free Tools to Scan Website Security Vulnerabilities & Malware

เข้าไล่มา 12 เครื่องมือ ผมก๊อปมาให้ดูตรงนี้อีกที (บางตัวก็ทำงานคล้ายๆ กัน)

  • Scan My Server – ตรวจหารูรั่วอย่าง SQL injection, PHP injection, HTTP Header injection, cross site scripting (XSS)
  • SUCURI – ตรวจหามัลแวร์ ลิงก์สแปม
  • Qualys SSL Server Test – ตรวจความปลอดภัยของการเข้ารหัสลับข้อมูลที่เว็บไซต์รับส่ง
  • Quttera – ตรวจหามัลแวร์และรูรั่วอื่นๆ
  • Detectify – ตรวจหาจุดอ่อน เช่นจุดอ่อนตามรายการ OWASP Top 10 ที่เว็บแอปโดนเจาะบ่อยๆ
  • SiteGuarding – ตรวจหามัลแวร์ ลิงก์สแปม
  • Web Inspector – ตรวจหา backdoor มัลแวร์ เฟรมหรือการเชื่อมต่อแปลกๆ
  • Acunetix – ตรวจหาความผิดปกติที่ระดับเครือข่าย อย่าง DNS รวมไปถึงการตรวจหารูรั่วอื่นด้วย
  • Asafa Web – ตรวจหาการใช้คุกกี้ที่ไม่ได้เข้ารหัสลับ clickjacking
  • Netsparker Cloud – ตรวจหารูรั่วประเภท injection, permission
  • UpGuard Web Scan – ตรวจหาความไม่ปลอดภัย โดยอาศัยข้อมูลที่บุคคลภายนอกสามารถดูได้ เช่น ตรวจว่ามีใครส่งอีเมลจากชื่อโดเมนเราได้ไหม
  • Tinfoil Security – ตรวจหาความไม่ปลอดภัย อย่างเช่นตามรายการ OWASP Top 10 และรูรั่วอื่นๆ

ที่ตรวจดูได้โดยไม่ต้องพึ่งผู้เชี่ยวชาญมากๆ ก็เช่น ติดมัลแวร์รึเปล่า การส่งข้อมูลได้เข้ารหัสลับ (https) ดีพอไหม พวกคุกกี้ของเว็บไซต์เราที่ไปฝากไว้กับเครื่องผู้ใช้นี่เว็บไซต์อื่นเข้ามาอ่านได้ไหม

ส่วนใหญ่จะฟรี บางอันต้องลงทะเบียนก่อน หรือต้องยืนยันสิทธิ์ก่อนว่าเราเป็นผู้ดูแลของเว็บไซต์นั้นจริงๆ (ด้วยการเอาไฟล์บางอย่างไปวางไว้ในเครื่องเรา – ยังไงก็ตรวจสอบดีๆ ก่อนจะเอาไฟล์อะไรไปวางนะครับ มันควรจะเป็น text/html file ที่เราเปิดเข้าไปอ่านๆ ได้ ถ้าดูแปลกๆ ก็อย่าทำต่อ)

* สำหรับตัวที่มีการทดสอบ SQL injection ให้ระวังด้วยว่ามันจะพยายามยิงอะไรบางอย่างเข้าไปในฐานข้อมูลของคุณ เพื่อจะทดสอบ แปลว่ามันอาจจะทำให้เกิดขยะในฐานข้อมูลได้  ดังนั้นไม่ควรทดสอบกับระบบที่ใช้อยู่จริง (on production) นะครับ ให้ทดสอบกับระบบที่เอาไว้ทดสอบเท่านั้น ถ้าเจอรูก็รีบอุด พอแน่ใจแล้วค่อยไปอัปเดตโค้ดในส่วนของ production ครับ [ขอบคุณคุณ Thitipong Samranvarnich ในกลุ่มสมาคมโปรแกรมเมอร์ไทย ที่เตือนเรื่องนี้ครับ]

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

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

(แต่ถ้าไม่พบ ก็ไม่ได้แปลว่าไม่มีนะครับ อาจจะแค่หาไม่เจอ)

ป้องกันคนมาดูภาพหรือไฟล์ที่ยังไม่พร้อมเผยแพร่

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

ถ้าเว็บเซิร์ฟเวอร์ใช้ Apache HTTP Server ก็ทำได้ด้วยการแก้ไขไฟล์ .htaccess โดยเพิ่มบรรทัด

Options -Indexes

ทีนี้ก็จะยังมีปัญหาอยู่บ้าง คือถ้าคนรู้ชื่อไฟล์ (อาจจะเดาไปเรื่อยๆ) เขาก็จะยังดูได้อยู่ดี

อันนึงที่ทำได้ก็คือ อย่าตั้งขึ้นไฟล์ให้มันเดาง่ายนัก (พวกรันเลขเรียงลำดับไปเรื่อยๆ นี่เดาสบายเลย)

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

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

Please do not leave the key in the lock

ปกปิดข้อมูลเว็บเซิร์ฟเวอร์

อีกอันที่ทำได้ไม่ยาก และช่วยให้การเจาะเว็บเราวุ่นวายขึ้นมาอีก “เล็กน้อย” คือปิดข้อมูลเกี่ยวกับเว็บเซิร์ฟเวอร์เราครับ

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

ถ้าเราปกปิดข้อมูลเกี่ยวกับเว็บไซต์เราเสียหน่อย ก็จะลดโอกาสเป็นเป้าไปไ้ด้บ้างจากนักเจาะที่ฉวยโอกาส

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

ยังไงก็ควรหมั่นอัปเดตรุ่นของซอฟต์แวร์ที่เขาแก้ไขเรื่องความปลอดภัยครับ

WordPress และ CMS อื่นๆ

ใครใช้เวิร์ดเพรส ลองดูหน้านี้ครับ มีอะไรที่พอทำตามได้บ้าง เช่นการตั้ง permission ของ directory ต่างๆ การปิดไม่ใช้แก้ไขไฟล์ของเวิร์ดเพรสผ่านหน้า dashboard ได้
https://codex.wordpress.org/Hardening_WordPress

คนใช้ Joomla, Drupal หรือ CMS อื่นๆ ลองเสิร์ชดูครับ ผมว่ามีแน่ๆ
https://docs.joomla.org/Security
https://www.keycdn.com/blog/drupal-security/

พอทำได้เบื้องต้นไปก่อน-แต่ในระยะยาวก็ต้องลงทุนน่ะ

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

แน่นอนว่าถ้าจะให้ดี ก็ควรปรึกษากับคนที่ชำนาญเรื่องความปลอดภัยของเว็บไซต์ (ซึ่งก็อาจจะมีค่าใช้จ่ายน่ะแหละ แต่อันนี้ก็ต้องไปอธิบายกันในองค์กรว่า มันสำคัญยังไง ทำไมถึงควรจ่าย – คิดมันอยู่ในหมวดเดียวกับรปภ.ไรงี้ได้ไหม อันนั้นยังจ่ายได้เลย :p)

คำเตือน

ผมไม่ใช่ผู้เชี่ยวชาญด้านนี้ ไม่ต้องมาถามผมเรื่องนี้ lol
ทั้งหมดนี้อาศัยจำจากเพื่อนๆ ที่เขาทำงานพวกนี้ และอ่านๆ เอาในเน็ตทั้งนั้น

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

ชุมชนความปลอดภัยเว็บ

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

https://www.facebook.com/groups/2600Thailand/
https://www.facebook.com/groups/owaspthailand/

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

อีกกรุ๊ปในเฟซบุ๊กที่ก็เข้าไปถามได้เหมือนกัน คือกลุ่มสมาคมโปรแกรมเมอร์ไทยครับ กลุ่มนี้ใหญ่และหลากหลายครับ https://www.facebook.com/groups/ThaiPGAssociateSociety/

เพิ่มเติม

  • คำแนะนำในการเก็บรหัสผ่านในระบบสำหรับนักพัฒนาซอฟต์แวร์ และผู้ดูแลระบบไอที@FordAntiTrust แนะนำวิธีการเก็บ “ข้อมูลตัวแทนรหัสผ่าน” ที่ทำให้เราไม่จำเป็นต้องเก็บรหัสผ่านต้นฉบับ ทำให้แม้ระบบถูกเจาะหรือข้อมูลรั่ว ข้อมูลที่หลุดไปก็ไม่ใช้รหัสผ่านที่เอาไปใช้ได้ทันที ต้องใช้เวลาในการย้อนรอยหารหัสผ่านจริงๆ ทำให้ผู้ใช้พอมีเวลาบ้างในการเปลี่ยนไปใช้รหัสผ่านใหม่
  • การออกแบบระบบให้รับ Request เยอะๆ — อันนี้ไม่ใช่ระดับพื้นฐานละ แต่เห็นว่าน่าสนใจดี เผื่อใช้เป็น reference เอาไปคุยตอนจ้างคนมาทำระบบ — คุณ ijemmy อธิบายแนวคิดเอาไว้ในโพสต์นี้ครับ (เรื่องจริงๆ ก็มีมุม security เหมือนกัน คือมุม availability หรือความพร้อมใช้ของระบบ ออกแบบยังไงให้ระบบไม่ล่มตอนมีคนใช้เยอะๆ พร้อมๆ กัน)

(เผยแพร่ครั้งแรกในเฟซบุ๊ก 1 พ.ค. 2018)

ภาพประกอบ “Key locker” โดย Jonathan O’Donnell สัญญาอนุญาตครีเอทีฟคอมมอนส์แบบแสดงที่มา-อนุญาตแบบเดียวกัน

National Digital ID

Aadhaar เป็นระบบยืนยันตัวตนแห่งชาติของอินเดีย ดูแลโดยหน่วยงานชื่อ UIDAI (Unique Identification Authority of India) ถ้าจะเทียบกับของไทยตอนนี้ก็คือโครงการ National Digital ID

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

แต่ก็นั่นแหละ ตั้งแต่เปิดใช้มา มีข่าวเจ๊ง หลุด รั่ว ล่ม แทบทุกสัปดาห์ (ลองดูข่าวที่ Software Freedom Law Centre, India และ Centre for Internet and Society รวบรวมมา) และปัญหาที่เกิด ไม่ได้มีเพียงปัญหาทางเทคโนโลยี แต่มีปัญหาที่เกิดระหว่างชิ้นส่วนที่เอามาประกอบกันด้วย และรูรั่วอีกมาจากคนหรือระบบการทำงานขององค์กร

Sunil Abraham จากศูนย์ Centre for Internet and Society ที่อินเดีย เขียนไว้น่าสนใจว่ามันอาจจะเกิดความผิดฝาผิดตัวในสมมติฐานการออกแบบระบบ

“This is because the digital identity solution for the nation as conceived by Aadhaar architects is based on the problem statement of digital identity within a firm. Within a firm all internal entities can be trusted. But in a nation state you cannot make this assumption.”

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

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

ก็เรียนรู้จากบทเรียนในอดีตของเรา กับบทเรียนในปัจจุบันของประเทศอื่นกันไปครับ

ใครสนใจโครงการ Digital ID Platform ของไทย เชิญได้ที่เว็บไซต์ www.digitalid.or.th ครับ มีร่าง White Paper ให้โหลดไปอ่านด้วย นอกจากนี้ยังมีกิจกรรม open forum อยู่เป็นระยะ ถ้าสนใจเข้าร่วมก็ติดต่อทีมงานได้ครับ ข่าวสารส่วนหนึ่งเผยแพร่ทางเฟซบุ๊กด้วยที่เพจ National Digital ID

 

Consumer information security tools – Thai localization 2017 summary

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

Thanks COCONET: Southeast Asia Digital Rights Camp and Localization Lab for a localization sprint this year for Thai, Bahasa Indonesia, Burmese, and Khmer. Events like that help volunteer translators get connected to people who close to developers, and it helps the translation submission goes more smooth.

รอผู้พัฒนาดำเนินการต่อ

แปล 100% รีวิว 100% รอให้าทางผู้พัฒนาทดสอบการใช้งานในแอป

A chart showing that Signal on Android 100% translated to Thai

ยังแปลไม่เสร็จ

รอให้ทางโครงการเพิ่มภาษาไทย

  • Gpg4win ชุดโปรแกรมสำหรับเข้ารหัสลับแบบ PGP (Windows)
    https://www.gpg4win.de/localize-gpg4win.html

    • มีโปรแกรมย่อยอีก 4 ตัวคือ GnuPG (โปรแกรมเข้ารหัสลับ), Kleopatra (โปรแกรมจัดการกุญแจ), GpgOL (ปลั๊กอินสำหรับ Outlook – เข้ารหัสลับอีเมล), GpgEx (ปลั๊กอินสำหรับ Windows Explorer – เข้ารหัสลับแฟ้ม)
    • อาจจะมีทางให้ Localization Lab ช่วยจัดการให้แปลผ่าน Transifex ได้

     

  • GPG Suite ชุดโปรแกรมสำหรับเข้ารหัสลับแบบ PGP (macOS) — Update 2018-01-05: เปิดให้แปลภาษาไทยได้แล้ว
    https://www.transifex.com/gpgtools/public/

    • มีโปรแกรมย่อยอีก 4 ตัวคือ libmacgpg (โปรแกรมเข้ารหัสลับ), GPG Keychain (โปรแกรมจัดการกุญแจ), GPGMail (ปลั๊กอินสำหรับ Mail.app), GPGPerferences (ส่วนการตั้งค่า)

     

  • Orbot, Orfox แอปช่วยเข้าถึงเน็ตอย่างเป็นส่วนตัวมากขึ้น (Android)
    https://www.transifex.com/otf/orbot/ (เทียบได้กับ Tor) — Update 2018-01-10: เปิดให้แปลภาษาไทยได้แล้ว
    https://www.transifex.com/otf/orfox/ (เทียบได้กับ Tor Browser)

สำหรับโปรแกรมที่อยู่บน Transifex แล้ว ใครสนใจช่วยแปล สามารถสมัครสมาชิก Transfex (ฟรี) แล้วไปที่หน้าโครงการ กด Join Team ได้เลยครับ — ถ้าโปรแกรมเหล่านี้เป็นภาษาไทย ก็มีโอกาสที่คนไทยจะสามารถใช้โปรแกรมช่วยความปลอดภัยเหล่านี้ได้มากขึ้นครับ

สวัสดีปีใหม่ 2018 ทุกท่าน ขอให้เป็นปีที่ปลอดภัย คิด ทำ พูด ได้อย่างมั่นใจ 🙂

จุดอ่อนของ AI ในงานความมั่นคงปลอดภัยทางสารสนเทศ #infosec17

ในงาน Infosecurity Europe 2017 นอกจากคำว่า GDPR และ IoT ที่เดินไปไหนก็เจอแล้ว ยังมีอีก 2 คำที่มาคู่กันให้เห็นไปทั่ว คือคำว่า artificial intelligence (ปัญญาประดิษฐ์) และ machine learning (การเรียนรู้ของเครื่อง)

หัวข้อหนึ่งที่ได้ไปฟังแล้วน่าสนใจคือ Adversarial Machine Learning: The Pitfalls of Artificial Intelligence-based Security โดยมี Giovanni Vigna ซึ่งเป็นอาจารย์ที่ UC Santa Barbara และหนึ่งในผู้ก่อตั้งบริษัท Lastline มาเป็นวิทยากร

Machine learning and security
Machine learning and security

หลักๆ คือ Giovanni พูดถึงว่า การมีข้อมูลให้เครื่องมันเรียนรู้ถึงรูปแบบมัลแวร์และการโจมตีต่างๆ ก็อาจจะทำให้คอมพิวเตอร์มันเก่งขึ้นได้ในการตรวจจับความผิดปกติ (anomaly detection) โดยอัตโนมัติ ซึ่งอันนี้ก็ใช้เทคนิค classification และ clustering ทำนองเดียวกับแอปพลิเคชันอย่างการรู้จำภาพ โดยเขายกตัวอย่างการหาความผิดปกติในจาวาสคริปต์ ที่ก็อาจจะใช้การวิเคราะห์ข้อมูลจาก abstract syntax tree (AST) เพื่อเปรียบเทียบกับจุดที่เคยมีข้อมูลมาก่อนว่าเป็นอันตราย

Identifying adversaries: Malicious evasive JavaScript
Identifying adversaries: Malicious evasive JavaScript

อย่างไรก็ตาม เช่นเดียวกับระบบปัญญาประดิษฐ์ทั่วไป ที่เครื่องมันก็อาจจะตอบผิดบ้าง (ทั้ง false negative – มีอันตรายจริงๆ แต่หลงหูหลงตาไป ไม่ได้แจ้งเตือน และ false positive – แจ้งเตือนว่าเป็นอันตรายทั้งที่จริงไม่ใช่) แต่นอกจากนั้นแล้ว การใช้ปัญญาประดิษฐ์ และโดยเฉพาะเจาะจงคือการเรียนรู้ของเครื่อง กับงานความมั่นคงปลอดภัยยังมีจุดอ่อนอยู่อย่างน้อยอีก 2 อย่าง หากผู้โจมตีสามารถศึกษาและเข้าใจโมเดลที่ระบบใช้ได้ (ซึ่งการได้มาซึ่งโมเดลนี่ก็อาจจะใช้วิธี reverse engineering เอาก็ได้ เช่นขโมยผ่าน machine learning APIดูเปเปอร์)

  • อย่างแรกคือ ศึกษาหาจุดบอดของโมเดล เพื่อสามารถรู้ได้อย่างเจาะจงมากขึ้นว่า ในกรณีไหน (ด้วย feature set แบบไหน ในเงื่อนไขไหน) ที่ระบบจะถูกหลอกได้ (ทั้ง false positive และ false negative) และนำจุดอ่อนนี้ไปหาประโยชน์ และ
  • อย่างที่สองคือ ศึกษาว่าการเรียนรู้ปรับปรุงโมเดลนั้นทำอย่างไร ใช้ข้อมูลทำนองไหน และหาทางป้อนข้อมูลที่สร้างขึ้นมาหลอกๆ เพื่อทำให้โมเดลเปลี่ยนไปในทางที่ต้องการ พูดอีกอย่างคือเป็นการทำให้โมเดลถูกปนเปื้อน (contaminated / polluted)

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

Adversarial machine learning is here
Adversarial machine learning is here

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

  • สภาพแวดล้อม (ข้อมูล) สำหรับการใช้ภาษาหรือรูปภาพ มันเปลี่ยนแปลงช้ากว่าสภาพแวดล้อมในโลกความมั่นคงทางสารสนเทศ (ที่มีมัลแวร์ใหม่ๆ เกิดขึ้นทุกวัน) และ
  • มันมีแรงจูงใจมากกว่าที่จะเอาชนะโมเดลในงานด้านความมั่นคง (ถ้าเราสามารถทำให้ Siri หรือ Google Translate ทำอะไรแปลกๆ ได้ ก็อาจจะตลกดี มีแรงจูงใจด้านความบันเทิง ความอยากรู้อยากเห็น ในขณะที่งานด้านความมั่นคงทางสารสนเทศมีแรงจูงใจด้านเศรษฐกิจหรือด้านการเมืองชัดเจน)

การใช้ AI ในงานความมั่นคงปลอดภัย จึงจำเป็นต้องระมัดระวังมากขึ้น คือมันมีคนพร้อมจะเล่นงานเมื่อคุณพลาด หรือถ้าคุณยังไม่พลาด เขาก็จะล่อลวงให้คุณพลาดให้ได้

แต่ในด้านกลับ ความรู้ที่เรียกว่า “adversarial machine learning” นี้ก็อาจจะถูกใช้เพื่อสร้างกับดักหรือกระทั่งตามล่าการโจมตีแบบใหม่ๆ ก็ได้ คือเอาไปหลอกคนที่จะมาโจมตีก็ได้

From trapping to hunting
From trapping to hunting

ตอบจบก่อนช่วงสรุป วิทยากรบอกให้เราตั้งคำถามให้ดี เวลามีใครมาเสนอขายระบบที่ใช้ AI หรือ Deep Learning (ซึ่งตอนนี้เป็นคำฮิตอีกคำ) เพื่อปกป้องความมั่นคงปลอดภัยทางสารสนเทศ (โน๊ต: วิทยากรก็มานำเสนอในฐานะตัวแทนบริษัทขายระบบพวกนี้เหมือนกัน)  คำถามเหล่านั้นก็คือ

  • ระบบดังกล่าวใช้เทคนิคอะไรมาประกอบกันบ้าง
  • ระบบใช้ข้อมูลชุดใดบ้างในการสอนโมเดล
  • ความสามารถในการป้องกันการถูกโจมตี (ตามที่โฆษณา) นั้นถูกประเมินอย่างไร
  • ประเมินภายใต้โมเดลภัยคุกคาม (threat model) แบบไหน?
  • วิธีที่ระบบใช้มี ความเที่ยง (precision) และ  การเรียกกลับ (recall) เท่าใด (ความเที่ยง หมายถึง จากจำนวนที่ระบบบอกว่าเป็นความผิดปกติ มีที่ผิดปกติจริงๆ เท่าใด, การเรียกกลับ หมายถึง จากจำนวนความผิดปกติที่มีอยู่จริงๆ ระบบสามารถพบได้เท่าใด)

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

What to ask about AI/ML/Deep Learning-based technology
What to ask about AI/ML/Deep Learning-based technology

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

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

Giovanni ตอบสั้นๆ ว่า มีคนคิดเรื่องนี้อยู่ แต่ ณ ขณะนี้ เทคโนโลยียังไปไม่ถึงตรงนั้น

ผมถ่ายมาไม่ครบทุกสไลด์ (เกรงใจ) คิดว่าอีกสักพักเขาน่าจะอัปโหลดไปที่ไหนสักที่ครับ ทางงานประชุมมีสรุปไว้ด้วย: #INFOSEC17 Machine Learning is Positive, but not a Security Solution

งาน Infosecurity Europe นี้ไม่ได้รู้จักมาก่อน (ผมไม่ใช่คนในวิชาชีพนี้โดยตรง เพียงแต่ต้องติดตามบ้างจากงานที่ทำงาน) เพิ่งจะรู้จากทวิตเตอร์ตอนที่ไปอยู่ลอนดอนได้สัปดาห์นึงแล้วนี่แหละ คือพวกผมไปกันอีกงานหนึ่งชื่องาน Mobile Media and Communication Practices in Southeast Asia เป็นงานสัมมนาวิชาการที่คณะสังคมวิทยาและมานุษยวิทยา ที่ธรรมศาสตร์ จัดร่วมกับ Goldsmiths Media Ethnography Group มหาวิทยาลัยลอนดอน ไม่ค่อยเกี่ยวกับด้านความมั่นคงปลอดภัยทางสารสนเทศเท่าไหร่ (แต่ก็มีหัวข้อนึงที่อาจารย์จาก Goldsmiths วิเคราะห์นโยบาย Thailand 4.0 และ Smart Thailand อาจจะเฉียดๆ)

อย่างไรก็ตาม ก็รู้สึกคุ้มค่าที่ได้ไป (ถ้ารู้เร็วกว่านี้อีกนิดก็จะดี จะได้ลงทะเบียนเข้าฟรี พอรู้ช้าต้องไปลงทะเบียนหน้างาน ต้องจ่าย 35 ปอนด์สำหรับงาน 3 วัน) ไปแล้วก็รู้สึกว่าอยากเขียนมาเล่า ยังไงอ่านอีกสองโพสต์ก่อนหน้าได้ครับ หลักการ/กลไกการคุ้มครองข้อมูลใหม่ใน GDPR ของสหภาพยุโรป และ ความมั่นคงปลอดภัยของ Internet of Things – ข้อคิดจาก Bruce Schneier

ร่างพ.ร.บ.ว่าด้วยการรักษาความมั่นคงปลอดภัยไซเบอร์ ใกล้จะคลอดเต็มทน ใครมีความคิดเห็นอะไรก็ส่งไปได้นะครับ แฟกซ์ 0-2281-2904 อีเมล legal@alro.go.th

Machine learning: The last line of defense
Machine learning: The last line of defense
Learn what your network does
Learn what your network does
Conclusions
Conclusions

ความมั่นคงปลอดภัยของ Internet of Things – ข้อคิดจาก Bruce Schneier ในงาน #infosec17

โพสต์ที่แล้วเล่าเรื่องงาน Infosecurity Europe วันที่สองไป เรื่อง General Data Protection Regulation (GDPR) จากมุมมอง ICO ยังเหลืออีกเรื่องที่ไปฟังมา คือเรื่อง ความปลอดภัยของ Internet of Things (IoT)

หัวข้อคือ Artificial Intelligence and Machine Learning: Cybersecurity Risk vs Opportunity? มี Bruce Schneier เป็นคนพูด คนแน่นมาก ตรงที่เป็นถ่ายทอดให้ดูทางจอก็ยังแน่น (ในภาพนี้เฉพาะที่นั่ง มียืนรอบๆ อีก)

Schneier พูดหลายประเด็น แต่อันหลังสุดมาเน้นเรื่องความมั่นคงปลอดภัยของ Internet of Things หรือ “อินเทอร์เน็ตของสรรพสิ่ง”

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

เราเปลี่ยนมือถือทุก 2-3 ปี กล้องวงจรปิดทุก 5-10 ปี ตู้เย็นบางบ้าน 20 ปี รถยนต์ที่มีตลาดมือสองอาจมีอายุการใช้งาน 40-50 ปี

คนทำซอฟต์แวร์ควบคุมรถยนต์ทำแล้วใช้ไปได้ 40-50 ปี แต่คนทำซอฟต์แวร์มือถือหรือ IoT ไม่เคยทำอะไรแบบนี้มาก่อน

ที่ซอฟต์แวร์ในบางอุตสาหกรรมมีความปลอดภัยสูง เพราะการกำกับดูแลและระบบนิเวศน์มันทำให้เป็นแบบนั้นได้ ต้องมีใบรับรอง มีการทดสอบ มีการตรวจสภาพ ซึ่ง IoT ยังไม่มีระบบนิเวศน์แบบนั้น

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

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

สำหรับอุตสาหกรรมนี้ มันไม่ใช่ทางเลือกระหว่าง “กำกับ vs ไม่กำกับ” แต่เป็นระหว่าง “กำกับอย่างฉลาด vs กำกับอย่างโง่” (smart regulation vs stupid regulation)

เขาทิ้งท้ายว่า ในบางประเทศเริ่มมีความเคลื่อนไหวเรื่องนี้แล้ว ว่าจะทำอย่างไรให้ผู้ผลิตอุปกรณ์พวกนี้ “รับผิดชอบ” กับผู้ใช้มากขึ้น — เช่นในสหรัฐอเมริกา ที่ FTC และ FCC สอบสวนว่าทำไมผู้ผลิตโทรศัพท์ออกอัปเดตความปลอดภัยช้า หรือที่หน่วยงานคุ้มครองผู้บริโภคของเนเธอร์แลนด์ฟ้องซัมซุงและเรียกร้องให้ออกอัปเดตความปลอดภัยอย่างสม่ำเสมอตลอด 2 ปีนับจากวันที่ซื้อ

ใครสนใจงานนี้ ติดตามแฮชแท็ก #infosec17 ได้ในทวิตเตอร์ครับ ส่วนเรื่อง AI กับ security มีอีกโพสต์เรื่อง adversarial machine learning

บูต Pen Test Partners โชว์เจาะระบบข้าวของเครื่องใช้ภายในบ้าน ทั้งกล้องวงจรปิด ตุ๊กตา เครื่องดูดฝุ่น กลอนประตู
บูต Pen Test Partners โชว์เจาะระบบข้าวของเครื่องใช้ภายในบ้าน ทั้งกล้องวงจรปิด ตุ๊กตา เครื่องดูดฝุ่น กลอนประตู

หลักการ/กลไกการคุ้มครองข้อมูลใหม่ใน GDPR ของสหภาพยุโรป #infosec17

วันนี้เป็นวันที่ 2 ที่มางาน Infosecurity Europe ที่ลอนดอน ได้ฟังหลักๆ 2 เวที เป็น Keynote ทั้งคู่ อันแรกตอนเช้า ฟัง Bruce Schneier พูดหัวข้อ Artificial Intelligence & Machine Learning: Cybersecurity Risk vs Opportunity? ส่วนตอนบ่ายฟัง EU GDPR Special Focus – Extended Session โพสต์นี้เล่าของตอนบ่ายก่อน ส่วนของตอนเช้ากับของงานวันแรกยังไม่ได้เขียนถึง เดี๋ยวทยอยลงนะ

เรื่อง General Data Protection Regulation (GDPR) ซึ่งเป็นกฎหมายคุ้มครองข้อมูลตัวใหม่ของสหภาพยุโรปที่ประกาศเมื่อปีที่แล้วและจะมีผลบังคับใช้ในวันที่ 25 พฤษภาคม 2018 นี่มาแรงมากๆ เดินไปไหนในงานก็เห็นคำนี้ มีในเกือบทุกทอล์ก เพราะเหลือเวลาอีกไม่ถึง 1 ปีแล้ว ที่ทุกบริษัท ทุกหน่วยงาน จะต้องปฏิบัติตามกฎหมายดังกล่าว ซึ่งมีผลบังคับใช้เหมือนกันหมดทั่วสหภาพยุโรป (หัวข้อตอนบ่ายที่ไปฟังมาอันนี้ฮิตมาก คนต่อแถวยาวเหยียด และเวลาก็ได้ยืดมากกว่าหัวข้ออื่น เป็น extended session)

Ready for GDPR (?)

Peter Brown ซึ่งเป็นเจ้าหน้าที่เทคโนโลยีอาวุโสของ Information Commissioner’s Office (ICO – สำนักงานคณะกรรมการข้อมูลข่าวสารของสหราชอาณาจักร) เป็นคนพูดเปิด เล่าถึงหลักการทั่วไปของ GDPR กับความพร้อมของ ICO ในฐานะองค์กรกำกับและคุ้มครองข้อมูลส่วนบุคคลของสหราชอาณาจักร ว่าได้เตรียมข้อแนะนำและหลักปฏิบัติอะไรต่างๆ ให้กับภาคธุรกิจปรับตัวและเปลี่ยนผ่านอย่างไรบ้าง

Peter บอกว่าหลักการคุ้มครองข้อมูลของ GDPR นั้น ไม่ต่างจากที่กฎหมายคุ้มครองข้อมูล หรือ Data Protection Act (DPA) ที่สหราชอาณาจักรมีอยู่ในปัจจุบัน เพียงแต่เพิ่มหลักการขึ้นมา 2 เรื่อง คือ Security และ Accountability & Governance

อธิบายต่อ (ผมพูดเอง) ก็คือ เดิม DPA นั้นพูดถึงเฉพาะตัวข้อมูลและการประมวลผลข้อมูล แต่ GDPR ยังพูดถึงระบบที่ใช้ประมวลผลข้อมูล (เน้นเชิงเทคนิค – technical measures) และความรับผิดและการบริหารจัดการของผู้ที่เกี่ยวข้อง (เน้นเชิงกระบวนการ – organizational measures)

จริงๆ ข้อคำนึงเหล่านี้ มีอยู่แล้วเงียบๆ ใน DPA แต่ GDPR ระบุให้มันแยกออกมาอย่างชัดเจน

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

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

สิ่ง “ใหม่” ที่ถูกพูดถึงในหลักการ Accountability & Governance ของ GPDR ก็คือหลัก data protection by design, data protection by default, และ data protection impact assessment (DPIA) — “ใหม่” ในที่นี้ หมายถึงมันไม่เคยถูกบังคับในกฎหมายมาก่อน

(เรื่อง data protection by design นี่ มีหลายบริษัทที่มาออกงานพูดถึง ตั้งแต่การออกแบบ user experience ที่สนับสนุน security, การทำระบบให้ลด cognitive load เพื่อให้คนทำงานอยู่ในภาวะมีสติ, การออกแบบให้ AI มาช่วยคนตัดสินใจได้ดีขึ้น)

ทั้งหลักการ Security และ Accountability ที่มีใน GDPR เรียกว่าเป็นความพยายามให้เกิดสภาพแวดล้อมที่ลดความเสี่ยงในการรั่วไหลของข้อมูล ไม่ได้มาเน้นเฉพาะการลงโทษหลังข้อมูลรั่วแล้ว นอกจากนี้ ในส่วนของ Security ก็ยังมีการกำหนดมาตรฐานการแจ้งเตือนในกรณีที่พบข้อมูลรั่วไหล (ทาง Article 29 Working Party จะออกแนวปฏิบัติมาภายในปีนี้)

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

หน้าที่ของผู้ประมวลผล-ผู้ควบคุมข้อมูลคือ จะต้องสามารถแสดงหลักฐาน (evidence) ให้ได้ว่า ตัวเองได้ทำสิ่งที่ควรทำทั้งหมดแล้ว

ลองคิดถึงกฎหมายเกี่ยวกับความปลอดภัยของอาคาร ที่ต่อให้ไฟยังไม่ไหม้ แต่ถ้าพบว่าไม่มีทางหนีไฟ ไม่มีอุปกรณ์จับควัน-แจ้งเตือน-ดับเพลิง ที่ได้มาตรฐานอย่างเพียงพอ ก็มีความผิดอยู่ดี

ใน GDPR หากมีกรณีข้อมูลรั่วไหล หากผู้ประมวลผล/ผู้ควบคุมข้อมูลสามารถแสดงได้ว่า ได้ทำตามมาตรฐานที่กำหนด ยังมีโอกาสได้รับลดหย่อนโทษลงด้วย

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

ยากและไม่ค่อยปลอดภัย Facebook Wi-Fi #FAIL @ ห้องสมุด TCDC

วันนี้มีสัมภาษณ์ เลยลองนัดที่ TCDC ใหม่ ตรงไปรษณีย์กลาง บางรัก ช่วงนี้จนถึงสิ้นเดือนพฤษภาคมเขาเปิดให้ใช้ห้องสมุดฟรี

พบว่าการใช้ไวไฟที่นี่วุ่นวายไปหน่อย คือคงตั้งใจดี ทางหนึ่งก็จะได้ยอดเช็กอินเพิ่ม อีกทางก็คงอยากให้ผู้ใช้ล็อกอินได้ง่ายๆ เลยใช้ Facebook Wi-Fi ในการลงทะเบียน (พูดอีกแบบคือ ฝากภาระในการบันทึกผู้เข้าใช้ระบบให้เฟซบุ๊กทำ – จะไม่ทำเลยก็คงไม่ได้ เพราะพ.ร.บ.คอมพิวเตอร์กำหนดให้บันทึกข้อมูลการจราจร-ที่ระบุตัวผู้ใช้ได้)

รวมๆ คือเราพบว่าการล็อกอินไวไฟที่ TCDC ไม่ค่อยเป็นมิตรเท่าไร แถมอาจส่งเสริมพฤติกรรมเสี่ยงด้านความปลอดภัยของข้อมูลส่วนบุคคล โพสต์นี้จะบอกว่าทำไม ปัญหาน่าจะอยู่ตรงไหน และน่าจะแก้ไขยังไงได้บ้าง (ใครใช้ Facebook Wi-Fi ก็อาจจะเจอปัญหาแบบเดียวกันนี้ได้ ไม่เฉพาะ TCDC – เคยเจอร้านกาแฟบางร้านก็ใช้)

มั่นใจว่าไม่ได้เจอปัญหานี้อยู่คนเดียว เพราะระหว่างที่นั่งทำงานอยู่ที่นั่นตั้งแต่ประมาณ 12:40 จนถึงราว 17:00 ได้ยินโต๊ะรอบๆ ถามกันเป็นระยะถึงเรื่องต่อไวไฟ กดตรงไหน ทำไมต่อไม่ได้

บางส่วนอาจจะเกี่ยวกับ UI (เช่น พอ CSS ไม่โหลด ตำแหน่งของแบบฟอร์มที่จะต้องกรอกก็สับสน) แต่ยังมีส่วน UX ด้วย ที่ประสบการณ์ตั้งแต่ต้นจนจบกว่าจะต่อเน็ตได้มีอุปสรรคพอสมควร ซึ่งถ้ายังยืนยันจะใช้ Facebook Wi-Fi อยู่ คงต้องหาทางไปตั้งค่าให้ถูกต้องและรองรับผู้ใช้ที่มีความต้องการหรือข้อจำกัดแตกต่างกันไป

นี่คือเครือข่ายไวไฟที่พบที่บริเวณห้องสมุดชั้น 5 ของ TCDC (จับภาพหน้าจอมาเมื่อ 19 พ.ค. 2560 ประมาณ 14:30)

TCDC wifi list

Guest@TCDC เป็นเครือข่ายสำหรับผู้ใช้ทั่วไป ส่วน Member@TCDC นั้นสำหรับสมาชิก (บุคคลทั่วไป 1,200 บาท/ปี นักศึกษา 600 บาท/ปี) เนื่องจากเรายังไม่ได้เป็นสมาชิก ก็ลองเลือก Guest@TCDC

ซึ่งก็เหมือนกับการเข้าใช้เครือข่ายไวไฟสาธารณะทั่วไป ที่เราคาดได้ว่าจะมีหน้าจอล็อกอินขึ้นมา ให้ใส่ชื่อหรือรหัสเพื่อเข้าใช้ ของ Guest@TCDC ก็จะเด้งหน้าจอนั้นขึ้นมา เพียงแต่มันจะแสดงคำเตือนนี้มาคั่นก่อน

Cannot verify identity of the log in page

ซึ่งหมายความว่า เว็บเบราว์เซอร์ของเรา ไม่สามารถตรวจสอบได้ว่า หน้าเว็บสำหรับการล็อกอินซึ่งอ้างว่าอยู่ที่หมายเลขไอพี 172.16.170.13 นั้น อยู่ที่หมายเลขไอพีดังกล่าวจริงๆ หรือไม่ เนื่องจากใบรับรอง (certificate) ที่เว็บเบราว์เซอร์ได้รับจากหน้าจอล็อกอิน เป็นใบรับรองที่ไม่ได้รับความน่าเชื่อถือ

ถ้ากด “Show Certificate” เพื่อดูรายละเอียดก็จะพบว่า เป็นใบรับรองที่ออกโดย Root Certificate Authority (Root CA – หน่วยงานออกใบรับรองระดับบนสุด) ที่ชื่อว่า cmx.cisco.com และจะหมดอายุวันที่ 12 ตุลาคม 2560 เวลา 01:59:08 (UTC+7) แต่เว็บเบราว์เซอร์ของเรา ไม่เชื่อถือ Root CA รายนี้ มันก็เลยขึ้นคำเตือน

เครือข่ายไวไฟ Member@TCDC ก็พบปัญหาเดียวกัน

ถ้าอยากจะใช้งานเครือข่ายไวไฟ ก็จำเป็นต้องไปให้ถึงหน้าล็อกอินให้ได้ จะไปให้ถึงหน้าล็อกอิน ก็ต้องยอมกด “Continue” ไป ทั้งๆ เราไม่แน่ใจว่ามันปลอดภัยหรือไม่ หรือจะเกิดอะไรขึ้นหลังจากนี้

พอกด Continue ไปแล้ว จะเจอหน้าจอให้ “เช็กอินบน Facebook เพื่อรับการเข้าถึงอินเทอร์เน็ตฟรี”

แต่หน้าจอเช็กอิน/ล็อกอินนี้ จะสับขาหลอกนิดหน่อย เพราะช่องล็อกอินที่เราเห็นเด่นๆ มันไม่ใช่อันที่จะต้องใช้ เราต้องเลื่อนหน้าลงไปอีก ถึงจะเจอฟอร์มที่ใช่ (ปัญหาอาจจะมาจากการที่ CSS ไม่ยอมโหลดด้วย – แต่ลองทั้งมือถือและเดสก์ท็อปก็เป็นเหมือนกัน)

เลื่อนหน้าจอล็อกอินลงมาหน่อย จะเจอคำว่า “หากต้องการเช็กอิน ให้สมัครใช้งาน Facebook วันนี้ หรือคลิกที่ลิงก์ ‘ข้ามการเช็กอิน’ ข้างล่างนี้” ให้มองหาลิงก์ “เข้าสู่ระบบ” (มันจะอยู่ติดกับลิงก์ “สมัครใช้งาน” เลย วรรคก็ไม่ยอมเว้น) พอคลิกที่ลิงก์ “เข้าสู่ระบบ” มันจะนำเราไปที่หน้าล็อกอินที่ถูกต้อง

(ลิงก์ “ข้ามการเช็กอิน” นั้นไม่สามารถคลิกได้ – ส่วนช่องที่เขียนว่า “ป้อนรหัส Wi-Fi” นั้นก็ใช้ไม่ได้ สอบถามเจ้าหน้าที่ TCDC แล้ว ไม่มีการออกรหัสให้ใช้กับช่องนี้)

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

ถ้ามาถึงหน้าจอนี้ หมายถึงใกล้สำเร็จแล้ว แต่เราจะเจอปัญหากับใบรับรองเหมือนกับที่เราเจอไปแล้วทีหนึ่ง ตรงนี้เว็บเบราว์เซอร์จะแจ้งว่ามันไม่สามารถยืนยันได้ว่าหน้าจอนี้ที่อ้างว่ามาจากหมายเลขไอพี 1.1.1.1 นั้นเป็นอย่างที่อ้างจริงๆ ถ้าเราเชื่อใจ อยากไปต่อ ก็ให้กด “Continue” อีกทีหนึ่ง

บนมือถือ (iOS) จะเป็นแบบนี้

Canno Verify Server Identity "1.1.1.1"

ถ้ากด “Continue” ก็จะมีหน้าจอให้เช็กอิน ประกาศให้โลกรู้ว่าเรามาอยู่ที่ TCDC แล้วนะ พอเราเช็กอินเสร็จ ก็จะใช้อินเทอร์เน็ตได้แล้ว

สรุป

พบว่าการเข้าใช้เครือข่ายไวไฟ Guest@TCDC นั้นเป็นประสบการณ์ที่ยากลำบากมาก โดยปัญหาที่พบคือ

  • พบปัญหาใบรับรองออกโดย CA ที่เว็บเบราว์เซอร์ไม่ให้การยอมรับถึง 2 ครั้ง ทั้งช่วงก่อนหน้าจอล็อกอินและช่วงใกล้จะล็อกอินสำเร็จ
    • ผู้ใช้ทั่วไปอาจจะทำตัวไม่ถูกว่าให้ทำอย่างไรต่อ เพราะข้อความเตือนของเว็บเบราว์เซอร์อาจเข้าใจยาก
    • กรณีผู้ใช้ TCDC ถูกสอนว่า “ไม่ต้องสนใจ คลิก Continue” ไปเลย ก็จะเป็นการส่งเสริมพฤติกรรมเสี่ยงให้กับผู้ใช้ โดยอาจเข้าใจไปว่า ต่อไปหากเจออาการแบบนี้อีกไม่ว่ากับเครือข่ายไหน หากอยากไปต่อ ก็ให้กด “Continue” เสีย ก็จะแก้ปัญหาได้ พฤติกรรมเช่นนี้ทำให้ผู้ใช้อาจตกเป็นเหยื่อของอาชญากรรมคอมพิวเตอร์หรือข้อมูลส่วนบุคคลถูกขโมยได้
    • ปัญหาใบรับรองนี้ พบว่าไม่ได้เป็นเฉพาะกับหน้าจอล็อกอินไวไฟของ TCDC หน้าเว็บไซต์หลักของ TCDC ก็มีปัญหานี้ด้วย 🙁TCDC Bad Certificate
  • หน้าจอ Facebook Wi-Fi ในบางกรณี อาจแสดงผลไม่ชัดเจนเพียงพอ ว่าผู้ใช้จะต้องกรอกแบบฟอร์มล็อกอินอันไหน ผู้ใช้ไม่สามารถรู้ได้เองอย่างชัดเจน ว่าจะต้องเลื่อนหน้าจอลงมาเพื่อคลิกลิงก์ “เข้าสู่ระบบ” เพื่อจะไปยังหน้าจอล็อกอินอีกอัน ซึ่งจะสามารถนำไปสู่การเช็กอินและใช้อินเทอร์เน็ตได้
  • ใครไม่มีบัญชีเฟซบุ๊กจะใช้อินเทอร์เน็ตผ่านเครือข่าย Guest@TCDC ไม่ได้ เนื่องจากผู้ใช้จะต้องล็อกอินเฟซบุ๊กก่อน
    • หรือถ้าวันไหนเฟซบุ๊กล่มหรือถูกปิดไป ก็อาจจะล็อกอินไม่ได้เหมือนกัน
    • เจ้าหน้าที่ Info Guru ที่ TCDC ยืนยันว่าไม่มีรหัสให้ป้อนเพื่อข้ามการล็อกอินเฟซบุ๊ก
  • ผู้ใช้ถูกบังคับให้ต้องเช็กอิน เนื่องจากลิงก์ “ข้ามการเช็กอิน” ใช้งานไม่ได้  ซึ่งก็คงไม่ใช่ผู้ใช้ทุกคนที่รู้สึกสะดวกเช็กอินหรือรู้วิธีการตั้งค่าโพสต์เช็กอินให้เป็นส่วนตัว (สำหรับ Facebook Wi-Fi เจ้าของหน้าเฟซบุ๊กอย่าง TCDC สามารถตั้งค่า “โหมดบายพาส” ให้ผู้ใช้ไม่ต้องเช็กอินก็ได้ แค่ล็อกอินเฟซบุ๊กก็พอ)
    • สอบถามเจ้าหน้าที่เพิ่มเติม ได้ข้อมูลว่า ถ้าเป็นบนมือถือ จะข้ามได้ แต่เท่าที่ลองบนเดสก์ท็อปข้ามไม่ได้
  • กรณีผู้ใช้ใช้การยืนยันตัวตนแบบสองชั้นและล็อกอินผ่านมือถือเครื่องเดียวกัน จะมีเวลาไม่เกิน 30 วินาทีในการล็อกอิน เนื่องจากถ้าสลับหน้าจอมาเพื่อดูโค้ด หน้าล็อกอินจะหายทันที
  • แถม: พบว่าโปรแกรมอีเมล (อย่าง Mail บน macOS กับ iOS หรือ Thunderbird) ใช้ไม่ได้ พอร์ต 993 (SSL/TLS encrypted IMAP) และ 465 (SSL/TLS encrypted SMTP) ถูกปิด และแอปแชต Signal ก็ใช้ไม่ได้

ข้อเสนอแนะ

  • ที่แก้ไขได้โดยไม่ต้องรอฝ่ายนโยบายนัก เพราะน่าจะเป็นเรื่องการตั้งค่าเครือข่าย คือเรื่องใบรับรองและเรื่องหน้าจอล็อกอิน กรณีใช้ Cisco น่าจะลองดูเอกสารตรง Clients Redirected to External Web Authentication Server Receive a Certificate Warning กับ Cisco Wireless 1.1.1.1/login.html redirect issues (ผมไม่มีความรู้เรื่องการติดตั้งระบบเครือข่ายใดๆ นี่เป็นการลองค้นข้อมูลเบื้องต้นเท่านั้น)
  • ปัญหาการโหลด CSS ไม่ขึ้น ส่งผลให้การใช้งานหน้าจอล็อกอินสับสน ควรหาทางแก้ไข (ผมไม่แน่ใจว่าเกิดเพราะอะไร)
  • ควรอย่างยิ่งที่จะมีทางเลือกให้ผู้ที่ไม่ได้ใช้เฟซบุ๊ก หรือไม่สะดวกจะล็อกอินด้วยเฟซบุ๊ก (เช่นติดปัญหาการยืนยันตัวตนแบบสองชั้น) ให้สามารถกรอกรหัสไวไฟเพื่อเข้าใช้งานได้ (เลือกใน Facebook Wi-Fi ได้)
  • ควรมีทางเลือกให้ผู้ใช้เฟซบุ๊กหลังจากล็อกอินแล้วไม่จำเป็นต้องเช็กอินก็ใช้งานได้ (เลือกใน Facebook Wi-Fi ได้)
  • พิจารณาเปิดพอร์ตพื้นฐานอย่างอีเมล (IMAP, POP, SMTP)

ใครมีโอกาสก็มาลองใช้งานดูครับ TCDC ใหม่ ทางเข้าห้องสมุดอยู่ชั้น 5 หลังจากนี้ถ้าไม่ใช่สมาชิก ก็ใช้บริการได้ โดยจ่ายค่าบริการรายวัน 100 บาท/วัน มีโต๊ะทำงาน มีปลั๊กไฟ มีไวไฟ (ถ้าเข้าได้) ถูกกว่าไปนั่งร้านกาแฟอีก (ถ้าไม่รวมค่ารถ :p) นอกจากนี้ยังมีส่วนนิทรรศการ Maker Space และส่วนอื่นๆ อีก

อ้อ นอกจากที่กรุงเทพ ที่เชียงใหม่ก็มี TCDC นะ และที่ขอนแก่นก็กำลังจะเปิด (ตอนนี้มี mini TCDC อยู่ในมหาวิทยาลัยขอนแก่นอยู่แล้ว)

ติดตั้ง HTTPS พร้อมใบรับรองฟรีจาก Let’s Encrypt บน shared host​ (DreamHost)

Let’s Encrypt เป็นบริการออกใบรับรองการเข้ารหัสเว็บ ที่ให้บริการฟรี ที่ผ่านบริการนี้ต้องเสียเงิน ประมาณ 500 บาทไปจนถึงเกินหมื่นก็มี ซึ่งในทางเทคนิคแล้ว ใบรับรองพวกนี้เหมือนกันหมดไม่ว่าจะฟรีหรือจ่ายเท่าไรก็ตาม

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

อย่างไรก็ตาม ณ ตอนนี้ สคริปต์ของ Let’s Encrypt นี่มันจะใช้บนเครื่องที่เรามี permission เข้าถึง root ของเซิร์ฟเวอร์ได้เท่านั้น คนใช้ shared host นี่หมดสิทธิ์

แต่ช้าก่อน — ถ้าใครใช้ DreamHost หรือเว็บโฮสต์ที่อนุญาตให้เราติดตั้งใบรับรองได้เองทางหน้าเว็บ ก็ไม่ต้องเสียใจ มีวิธีอยู่ คือเรารันสคริปต์นั่นในเครื่องโน๊ตบุ๊กหรือเดสก์ท็อปของเราเองก่อน (บน Linux หรือ OS X) แล้วจากนั้นก็ค่อยเอาไฟล์ต่างๆ ไปใส่ไว้ใน Dreamhost อีกที ผ่านคอนโทรลพาเนลบนหน้าเว็บปกติ

ขั้นตอนวิธีทำเอามาจาก Using Let’s Encrypt With Dreamhost โดย jmhobbs

  1. เริ่มจากไปบอก DreamHost ก่อนว่าให้เพิ่ม secure hosting ไปที่ชื่อโดเมนของเรา
    ล็อกอินเข้า DreamHost panel ที่ด้านซ้ายเลือก “Domains” –> “Secure Hosting” –> “Add Secure Hosting” (ใครใช้ shared host ยี่ห้ออื่น ลองหาทางดูครับ อาจจะมีคล้ายๆ กัน)
    Add secure hosting in Dreamhostตรงนี้เราก็เลือกชื่อโดเมนที่เราต้องการให้มีการเข้ารหัส
    Choose domain name to add secure hosting
    จบขั้นนี้ปุ๊บ สิ่งที่เราได้ก็คือ ชื่อโดเมนที่เราเลือก จะมีการเข้ารหัสด้วย HTTPS แล้ว แต่ใบรับรองที่ใช้จะเป็น self-signed (เซ็นรับรองด้วยตัวเราเอง) ซึ่งเวลาใครมาเข้าเว็บไซต์เรา เบราว์เซอร์มันก็จะเตือนว่า ไม่น่าเชื่อถือนะ สิ่งที่เราจะทำต่อไปก็คือ ไปขอใบรับรอง ที่ Let’s Encrypt (บุคคลที่สาม) เป็นคนเซ็นให้เรา เพื่อให้เบราว์เซอร์มันพอใจ (และคนอุ่นใจ)
  2. ก่อนจะใช้ Let’s Encrypt ก็ต้องติดตั้งมันลงเครื่องโน๊ตบุ๊กหรือเดสก์ท็อปของเรา
    โดยไปดึงสคริปต์มาด้วย git (ถ้ายังไม่มี ก็ติดตั้ง git ก่อน)

    git clone https://github.com/letsencrypt/letsencrypt
  3. จากนั้นก็ ขอใบรับรอง ด้วยสคริปต์ของ Let’s Encrypt
    cd letsencrypt
    ./letsencrypt-auto certonly --manual --debug

    คำอธิบายอ็อปชัน

    • certonly ระบุเพื่อบอกว่า ให้สร้างใบรับรอง แต่ไม่ต้องติดตั้ง (เดี๋ยวเราติดตั้งเอง – ผ่านคอนโทรลพาเนลของ Dreamhost)
    • –manual บอกว่า เราจะทำ domain validation ยืนยันว่าเรามีสิทธิ์ในชื่อโดเมนนั้นเอง (ผ่านการเอาข้อความอันนึงไปวางไว้ที่เซิร์ฟเวอร์นั้น)
    • –debug ใส่อ็อปชันนี่ ถ้ารันบน OS X, ถ้าใช้ Linux ก็ไม่ต้องใส่

    ตรงนี้สคริปต์อาจจะติดตั้งโปรแกรมที่จำเป็นลงในเครื่อง เช่น libxml2, python2.7 (ถ้าบน OS X ก็ผ่าน homebrew) ก็ดูๆ ครับ ว่ามันสำเร็จไหม ถ้าไม่มีปัญหาอะไร สคริปต์ก็จะพาเราไปสู่ขั้นที่ 4

  4. สคริปต์จะถาม อีเมลของเรา (ใช้กรณีกู้กุญแจที่หาย)
    Let's Encrypt asking for e-mail
    และ ชื่อโดเมนที่เราต้องการใบรับรองLet's Encrypt asking for domain name
    ตรงขั้นนี้มันจะเตือนเราว่าทางระบบจะทำการบันทึก ที่อยู่ไอพี (IP address) ที่เราใช้เพื่อขอใบรับรองนะ เราโอเคไหมที่จะให้คนอื่นรู้ที่อยู่ไอพีที่เรากำลังใช้อยู่ขณะนี้ (ของเครื่องที่เรากำลังใช้อยู่ ไม่ใช่เว็บเซิร์ฟเวอร์) ถ้าเราโอเค ก็ตอบตกลงไป
    Let's Encrypt warns about IP logging
  5. ถึงตรงนี้มันจะให้เรายืนยันว่า เรามีสิทธิ์ในชื่อโดเมนที่เราขอไปจริงๆ ด้วยการให้เราสร้างไฟล์ที่มีชื่อตามที่มันกำหนดในไดเรกทอรีที่กำหนด (ตรงสีเขียว) โดยในไฟล์นั้นต้องมีข้อความที่กำหนดด้วย (สีแดง) — อย่าเพิ่งกด ENTER จนกว่าเราจะสร้างไฟล์ที่ว่าเสร็จ
    Let's Encrypt asking for domain validationวิธีสร้างก็ตามนี้ คือ (ในอีกหน้าจอนึง-ล็อกอินเข้าไปที่เซิร์ฟเวอร์ ไม่ได้ทำที่เครื่องเราเองนะ) เข้าไปที่ไดเรกทอรีของเว็บไซต์เราก่อน (อันนี้เป็นการแบ่งไดเรกทอรีในแบบของ Dreamhost ใครใช้โฮสต์อื่นก็ปรับไปนะครับ) จากนั้นก็สร้างไดเรกทอรีที่กำหนด แล้วก็สร้างไฟล์และเอาข้อความที่มันบอกไปใส่ เพื่อบอกว่า นี่ไง เราสร้างได้ เรามีสิทธิ์จริงๆ นะ

    cd [domain]
    mkdir -p .well-known/acme-challenge/
    echo -n "[RedContent]" > .well-known/acme-challenge/[GreenFilename]

    พอจัดการเรื่องที่เซิร์ฟเวอร์เสร็จ ก็กลับมาที่หน้าจอที่เครื่องเรา แล้วกด ENTER ได้เลย

    ถ้าระบบมันเจอไฟล์ที่เราสร้างไว้อย่างถูกต้องที่เซิร์ฟเวอร์ ระบบมันจะสร้างใบรับรองให้เรา เก็บไว้ที่ /etc/letsencrypt/live/[domain]
    ข้างในไดเรกทอรีดังกล่าวจะมีไฟล์อยู่ 4 ไฟล์: cert.pem, chain.pem, fullchain.pem, privkey.pem ซึ่งเราจะเอาไปใช้ในขั้นต่อไป
    **ไฟล์เหล่านี้อย่าให้คนอื่นรู้** ไม่งั้นเขาจะปลอมตัวเป็นเว็บไซต์ของเราได้

  6. ถึงตรงนี้เราจะเริ่มก๊อปปี้ใบรับรองต่างๆ ไปใส่ในคอนโทรลพาเนลของ Dreamhost
    เริ่มด้วยการคลิก Edit ที่ท้ายชื่อโดเมน ในหน้า “Secure Hosting”
    Add certificate in Dreamhostจะเจอหน้า “Certificate Settings”
    ให้เราเลือก “Manual configuration”
    มันจะขึ้นช่องให้เราใส่ใบรับรองต่างๆ อยู่ 4 ช่อง
    Add certificate in Dreamhost4 ช่องนี้ ให้ใส่ดังนี้

    • Certificate Signing Request: ลบทิ้งให้ว่าง
    • Certificate: เอาข้อความในไฟล์ cert.pem มาใส่
    • Private Key: แปลง privkey.pem เป็นฟอร์แมต RSA ด้วย openssl แล้วนำข้อความมาใส่
    • Intermediate Certificate: เอาข้อความในไฟล์ chain.pem มาใส่

    วิธีดูข้อความในไฟล์

    sudo less /etc/letsencrypt/live/[domain]/cert.pem

    วิธีแปลง privkey.pem เป็นฟอร์แมต RSA แล้วเอาไปเก็บไว้ที่ privkey.key (จากนั้นก็เอาข้อความใน privkey.key ไปใช้)

    sudo openssl rsa -in /etc/letsencrypt/live/bact.cc/privkey.pem -out privkey.key

    ใส่ครบทุกช่องแล้ว ก็คลิก “Save changes now”

  7. เท่านี้ก็น่าจะเสร็จแล้ว — แต่ถ้าอยากให้ทุกครั้งที่เรียก http://abc.xyz แล้วให้มัน redirect ไปที่ https:///abc.xyz อัตโนมัติ ก็ทำขั้นนี้เพิ่มหน่อย — ใส่โค้ดนี้ลงในไฟล์ .htaccess
    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
  8. ลองเข้าเว็บไซต์ของเราดู ว่าเข้ารหัสและมีใบรับรองสวยงามอย่างที่หวังไหม หลังการแก้ไขต่างๆ อาจจะต้องรอสักพัก ไม่น่าจะเกิน 15 นาที เพื่อให้ระบบมันรีเฟรช
  9. ทดสอบความเรียบร้อยอีกที ด้วย การทดสอบจาก SSL Labs เพื่อดูว่าเรายังขาดตกตรงไหนอีก
  10. อย่าลืมว่า ใบรับรองของ Let’s Encrypt จะหมดอายุทุกๆ 3 เดือน ดังนั้นพอใกล้ๆ 3 เดือนก็อย่าลืมทำซ้ำตั้งแต่ขั้นที่ 3 ใหม่นะครับ

ส่วนใครใจไม่ร้อน รอได้ ก็รออีกหน่อย ทาง Dreamhost ประกาศแล้วว่า จะหาทางให้สามารถใช้ Let’s Encrypt บน Dreamhost ได้แบบง่ายๆ แค่คลิกๆ ก็เสร็จ

[27 ก.ค.] ตะลุยแปล #Tor เป็นไทย เสาร์นี้

แปล Tor เป็นไทย

ชวนชาวเน็ตมาช่วยแปลโปรแกรม Tor เป็นภาษาไทยกันครับ 🙂

เสาร์ 27 กรกฎา ประมาณ 10 โมงเช้าไปจนถึง 5 โมงเย็น
ที่ร้านกาแฟ Tom N Toms สยามเซ็นเตอร์ [Facebook event]

Tor (The Onioin Router) เป็นโปรแกรมที่ช่วยให้เราใช้งานอินเทอร์เน็ตได้ปลอดภัยขึ้น และลดโอกาสการถูกดักฟังขโมยข้อมูลจากผู้ไม่หวังดี มีวิธีการใช้ไม่ยุ่งยากนัก แต่อุปสรรคสำคัญอย่างหนึ่งสำหรับผู้ไม่คุ้นเคยคือ หน้าจอโปรแกรมยังเป็นภาษาอังกฤษอยู่ ซึ่งการแปลเป็นไทย ก็จะช่วยให้คนอีกมากเข้าอินเทอร์เน็ตได้อย่างปลอดภัยครับ

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

โดยรวมตอนนี้แปลไปแล้ว 46% และยังรอตรวจคำแปลอยู่อีกครับ

ใช้โปรแกรมเข้ารหัสก็ยังไม่ปลอดภัย ถ้าโดนดักก่อนหน้านั้น

ตำรวจเยอรมนียอมรับ ใช้โทรจัน R2D2 สอดแนมประชาชนจริง

@jiew ส่งข่าวนี้จากบล็อก Naked Security มาให้ดู ก็เลยแปล จากข่าวนี้ก็ทำให้พบว่า Skype หรือโปรแกรมเข้ารหัสอะไรต่าง ๆ นั้นก็ไม่ได้ช่วยทำให้การสื่อสารของเราปลอดภัย ถ้าเกิดเราไม่ดูแลเครื่องของเราให้ดี ให้รอดพ้นไปจากพวกมัลแวร์สปายแวร์ทั้งหลาย ที่ดักข้อมูลในจังหวะที่ยังไม่ถูกเข้ารหัส … ปัญหาคือแล้วจะไปรู้ได้ยังไง ว่าเครื่องเรามีสิ่งเหล่านั้นติดตั้งอยู่

หรือควรจะใช้วิธีทำงานบน Live CD ? แบบเขียนไม่ได้ :p