Smartwatch กับตลาดที่ไม่กว้างอย่างที่คิด

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

ส่วนตัวใช้ smartwatch อย่าง Pebble Classic มา 1-2 ปี (ถ้าคำนวณไม่พลาด) แรกๆ ก็อัดความสามารถด้วยการใส่แอปลงไปเยอะๆ ควบคุมมือถือโน้น-นี่ได้มากๆ แต่สุดท้าย ก็ถอดออกเหลือแค่ watchface, แอปพื้นฐานจำพวกควบคุมแอปฟังเพลง, ดูสภาพอากาศวันนี้, รับข้อความ-แจ้งเตือน แล้วก็ activity tracking เพียงแค่นั้น ส่วนพวกอะไรเยอะๆ เอาออกไปหมดเลย เพราะมันใช้งานแล้วมันไม่สุด เพราะสุดท้ายก็ต้องหยิบมือถือมาใช้อยู่ดี ซึ่งก็พบว่า เออ smartwatch มันก็ทำได้ประมาณนี้ก็คงพอแล้วแหละ

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

แล้วมามองอีกมุมว่า ที่มันทรงๆ เงียบๆ คงเพราะตลาดมันก็ไม่กว้างมากพอ ผู้เล่นในตลาดเยอะ แถมต้องไปตบตีกับตลาดนาฬิกาเดิมอีก เพราะบางคนมีนาฬิกาตัวโปรดแพง ๆ อยู่แล้ว แล้วคนเรามีแค่มือซ้าย-ขวา แถมใส่นาฬิากาก็ควรใส่แค่เรือนเดียว ไม่เหมือนมือถือที่พก 2-3 เครื่องก็ยังดูไม่แปลกเท่าไหร่ เผลอๆ พื้นที่ sport band ยังมีให้เล่นมากกว่าเลย เพราะใส่นาฬิกาซ้าย ใส่ sport band ขวายังพอรับได้มากกว่าใส่นาฬิกาซ้าย-ขวา

สุดท้ายในด้านราคา ตัว smartwatch มันก็ไม่ถูกด้วย Pebble เข้าไทยก็โดดไป 8-9 พันบาทโน้น ต้องรอสอยตอนลดราคา ยิ่งไม่ต้องพูดถึงยี่ห้ออื่นๆ เกือบหมื่นหรือหลักหมื่นขึ้นทั้งนั้น สรุปเก็บตังซื้อมือถือดีกว่า

ลงทะเบียนล่วงหน้าบริการพร้อมเพย์ (PromptPay) แบบง่ายๆ กับกรุงศรี พร้อมเพย์ (Krungsri PromptPay)

บริการพร้อมเพย์ (PromptPay) หรือชื่อเดิมคือ Any ID เป็นบริการเพื่อเพิ่มช่องทางในการรับ-โอนเงินระหว่างกัน โดยเข้ามาแทนที่หมายเลขบัญชีธนาคารที่เราจดจำได้ยาก โดยรัฐบาลมีแนวคิดการจ่ายเงินสวัสดิการและการคืนภาษีต่าง ๆ ให้แก่ประชาชนผ่านเลขประจําตัวประชาชน และถือเป็นส่วนหนึ่งของโครงการพัฒนาระบบ โครงสร้างพื้นฐานระบบชำระเงินของประเทศไทย (National e-Payment)

โดยในระยะเริ่มต้นระหว่างวันที่ 1 – 14 กรกฎาคม 2559 จะเป็นการเปิดให้ผู้ใช้บริการลงทะเบียนล่วงหน้า โดยใช้เพียง เลขประจำตัวประชาชน หรือหมายเลขโทรศัพท์มือถือ ในการลงทะเบียนเพื่อผูกเข้ากับหมายเลขบัญชีธนาคาร และรายงานผลผ่านทาง SMS, อีเมลหรือไปรษณีย์หลังจากวันที่ 15 กรกฎาคม 2559

และตั้งแต่วันที่ 15 กรกฎาคม 2559 เป็นต้นไป สามารถลงทะเบียนผูกบัญชีกับธนาคาร และทางธนาคารจะแจ้งผลการลงทะเบียนได้ในทันที

วันนี้เลยมาแนะนำวิธีลงทะเบียนล่วงหน้าบริการกรุงศรี พร้อมเพย์ จากธนาคารกรุงศรีอยุธยา ผ่านหน้าเว็บให้ดูกัน

1. เข้าไปที่ ลงทะเบียนง่าย ๆ โดยเข้าไปที่ krungsri.com/promptpay

2. ทำการกรอก หมายเลขบัญชีธนาคารกรุงศรี, หมายเลขโทรศัพท์มือถือ และ รหัสประจำตัวประชาชน 6 หลักสุดท้าย

2016-07-01_121830

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

2016-07-01_122809c

4. หากเลือกลงทะเบียนด้วย หมายเลขบัตรประชาชน จะแจ้งผลการลงทะเบียน และทางธนาคารจะส่งผลการลงทะเบียนให้ทาง SMS อีกครั้งหนึ่ง ตั้งแต่วันที่ 15 กรกฎาคม 2559 เป็นต้นไป

2016-07-01_122857c

5. หากเลือกลงทะเบียนด้วยหมายเลขโทรศัพท์ จะมีการยืนยันหมายเลขโทรศัพท์ผ่าน OTP ก่อน อีก 1 ขั้นตอน แล้วจึงแจ้งผลการลงทะเบียน โดยทางธนาคารจะส่งผลการลงทะเบียนให้ทาง SMS อีกครั้งหนึ่ง ตั้งแต่วันที่ 15 กรกฎาคม 2559 เป็นต้นไป

2016-07-01_174828c

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

สำหรับข้อมูลอื่นๆ สามารถอ่านต่อได้ที่ เกี่ยวกับกรุงศรี พร้อมเพย์ (Krungsri PromptPay)

3152

 

ลองทดสอบใช้ AIS WiFi Calling บน iPhone 6

เมื่อวานช่วงกลางคืน (คืนวันที่ 17 มิ.ย. 59) เจอข้อความใน timeline บน Twitter แจ้งว่า AIS เปิดให้ใช้ AIS WiFi Calling ได้แล้วเลยลองทดสอบดู

โดยวิธีการเปิดใช้งานบน iPhone

  1. ให้อัดเดท Carrier เป็น AIS ตัว 24.2 (ดูได้ที่ Settings ตามด้วย General และ About)
  2. กดขอใช้บริการ AIS WiFi Call ผ่านเบอร์ *399*1# แล้วรอสักครู่
  3. เปิดใช้งานบนเครื่อง ให้ไปที่ Settings ตามด้วย Phone และ Wi-Fi Calling
  4. เปิดตัวเลือก WiFi Calling on This iPhone ขึ้นมา
  5. ลองกด Airplane Mode แล้วเปิดรับสัญญาณ WiFi อย่างเดียว ก็จะขึ้น AIS WiFi Call ด้านซ้ายมือบน

จากการทดสอบในการโทรศัพท์ ให้เสียงโอเค การตอบรับทำได้เร็วมาก โดยได้รับสัญญาเรียกทันที

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

ข้อดีของการใช้ WiFi Calling คือช่วยให้การรับบริการในบางพื้นที่ที่เป็นจุดอับสัญญาณ ยังสามารถใช้งานโทรศัพท์ได้อย่างทั่วถึง ตัวอย่างเช่นในคอนโด หรืออาคารที่ cell site ส่งสัญญาณเข้าไปได้ยาก พบว่าสัญญาณอ่อน หรือไม่มีสัญญาณ ซึ่งจะได้รับประโยชน์จากความสามารถนี้อย่างมาก

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

ณ ตอนที่ทดสอบยังไม่มีความสามารถ Calls on Other Devices และ Update Emergency Address แต่อย่างใด

13475057_10154196757430275_328057689083887579_o

ปัญหาการแจ้งวันและเวลาแข่งขันกีฬาที่อยู่ระหว่างช่วงเปลี่ยนวันของสื่อไทย

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

ตัวอย่างที่เห็นได้ชัดก็คือ Euro 2016 ในวันที่ 11 มิถุนายน 2559 จะมีโปรแกรมการแข่งขัน ที่สื่อไทยส่วนใหญ่ใช้คือ

11 มิถุนายน 2559

  • 20:00 น. แอลเบเนีย VS สวิตเซอร์แลนด์
  • 23:00 น. เวลส์ VS สโลวาเกีย
  • 02:00 น. อังกฤษ VS รัสเซีย

นี่คือตัวอย่างขนาดสื่อ Official ของไทยยังเป็นไปกับเค้าด้วย (อ้างอิง)

310(1)

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

11 มิถุนายน 2559

  • 02:00 น. ฝรั่งเศส VS โรมาเนีย
  • 20:00 น. แอลเบเนีย VS สวิตเซอร์แลนด์
  • 23:00 น. เวลส์ VS สโลวาเกีย

12 มิถุนายน 2559

  • 02:00 น. อังกฤษ VS รัสเซีย
  • 20:00 น. ตุรกี VS โครเอเชีย
  • 23:00 น. โปแลนด์ VS ไอร์แลนด์เหนือ

ดูตัวอย่างที่ดีจาก Google ก็น่าจะได้มั้ง

2016-06-11_220350ซึ่งจากปัญหาดังกล่าว ผมอยากถามสื่อไทยบางสื่อที่กำลังทำแบบผิดๆ ว่า พวกพี่จะย้อนเวลาหาอดีตกันเหรอครับ คือที่เจอนี่เจอกันเยอะเลย เป็นมานานมาก คือผมหล่ะหน่ายกับพวกพี่มานานมาก ช่วยแจ้งให้มันตามเวลามาตรฐานหน่อยเหอะ เพราะเรื่องวันและเวลานี่สำคัญมากๆ แจ้งผิดๆ ถูกๆ ไม่มีมาตรฐานเวลาชัดเจนแบบนี้คนตามดูมันลำบากมาก จนตอนนี้เวลาจะดูโปรแกรม ผมไม่ดูจากสื่อที่แจ้งเวลาผิดๆ พวกนี้เลย และถ้าพวกพี่กลัวคนไทยบางกลุ่มสับสนวันช่วงคาบเกี่ยว ก็แจ้งว่าคืนวันที่ X เช้าวันที่ Y แต่ยังคงเวลาที่ถูกต้องไป ก็น่าจะช่วยพี่ได้เยอะ (พี่แจ้ง time zone มาเลยก็ได้ GMT +7 อะไรแบบนี้กำกับมาด้วย คนจะได้เข้าใจว่าเวลาไทย)

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

แนะนำการใช้ HTTP Public Key Pinning (HPKP) เพื่อป้องกัน Certification Authority ออก TLS Certificate ซ้ำซ้อน

กระบวนการรับรอง SSL/TLS Certificate หรือ “ใบรับรองอิเล็กทรอนิกส์” (ต่อไปจะเรียกว่า TLS Certificate) จะผ่านทาง Certificate Authority หรือ “ผู้ออกใบรับรองอิเล็กทรอนิกส์” (CA)

โดยเว็บเบราว์เซอร์หรือระบบปฏิบัติการ (ต่อไปจะเรียกว่า client) จะมีรายการที่เรียกว่า Trusted Root Certification Authorities หรือ “รายการใบรับรองอิเล็กทรอนิกส์ของผู้ออกใบรับรองอิเล็กทรอนิกส์สำหรับผู้อื่น” อยู่ภายใน โดยมากมักอ้างอิงกับตัวระบบปฏิบัติการเป็นหลัก ซึ่งจะบรรจุ Root Certificate หรือ “ใบรับรองอิเล็กทรอนิกส์ลำดับชั้นบนสุด” เพื่อให้ client สามารถเชื่อใบรับรองอิเล็กทรอนิกส์ที่ได้รับรองจาก Certificate Authority เหล่านั้น (Trust any certificates issued by the Certificate Authorities)

การที่ Certificate Authority จะสามารถอยู่ในรายการดังกล่าวได้ จะต้องผ่านการตรวจสอบคุณสมบัติตามมาตรฐานจากหน่วยงาน CA/Browser Forum เพราะผู้ผลิต client ต่างๆ จะใช้ข้อมูลจาก CA/Browser Forum ในการบรรจุ Root Certificate ลงไปในซอฟต์แวร์ของตน (สมาชิกของ CA/Browser Forum)

รูปภาพจาก Root certificate

รายการ Trusted Root Certification Authorities ภายใน operating system ของ Windows

ปัญหาที่ระดับ Trusted Root Certification Authorities

จากการรับรองข้างต้น ดูเหมือนจะไม่มีปัญหาหากเครื่องของผู้รับบริการมีความปลอดภัย ไม่ถูกเพิ่มรายชื่อ Trusted Root Certification Authorities ใหม่แทรกเข้ามาได้ แต่หากพบปัญหา โดยมากมักถูกเพิ่มเข้ามาผ่านการติดตั้งซอฟต์แวร์ตัวอื่นๆ ภายหลัง ซึ่งมักจะเป็นจุดที่เจอได้ง่าย ตัวอย่างเช่น กรณีผู้ใช้โน้ตบุ๊ก Lenovo หลายรายพบว่าถูกติดตั้ง Adware มาจากโรงงาน, ดักฟังเว็บเข้ารหัส

แต่ยังมีอีกปัจจัยเสี่ยงคือ Trusted Root Certification Authorities เจ้าใดเจ้าหนึ่งในรายการที่เครื่องของผู้รับบริการถูกแฮก หรือเลินเล่อออกใบรับรองอิเล็กทรอนิกส์ของเว็บไซต์ซ้ำซ้อน จนทำให้มี TLS Certificate ที่เหมือนกับเว็บที่เราให้บริการ โดยเราที่เป็นผู้ให้บริการไม่ทราบ จึงทำให้การสื่อสารของบริการของเราสามารถถูกถอดรหัส และดักฟังได้โดยที่เรายังคงให้บริการได้เป็นปรกติ เหตุการณ์นี้ได้เกิดขึ้นแล้วกับ Google.com ผ่าน DigiNotar (รายละเอียดดูใน แฮกเกอร์สร้างใบรับรอง SSL สำหรับโดเมนของกูเกิลได้สำเร็จ, ทุกเว็บของกูเกิลเสี่ยงต่อการถูกดักฟัง) หรือ กูเกิลเตือนใบรับรองดิจิทัลปลอมจากอินเดีย มาแล้ว

Rogue-SSL-Certificate-Authority

รูปจาก What is Certificate Transparency? How It helps Detect Fake SSL Certificates

วิธีการต่างๆ ในการป้องกัน

จากเหตุการณ์ข้างต้น มีวิธีหลายวิธีในการป้องกันเหตุการณ์ดังกล่าว อย่าง การทำ DNS-Based Authentication of Named Entities (DANE) บน TLSA record ที่ระดับ DNS ร่วมกับการทำ DNSSEC แต่มีความยุ่งยากที่ต้องติดตั้งและดูแลระบบ DNS ที่มีการปรับปรุงเพื่อให้รองรับ DNSSEC และ DANE เพิ่มมากขึ้น รวมไปถึง client ก็ยังไม่รองรับเป็นการทั่วไปสักเท่าไหร่

2016-06-10_020012

แต่ก็ยังมีวิธีที่ง่ายกว่า และมีการรองรับโดยเบราว์เซอร์เจ้าใหญ่อย่าง Google Chrome และ Mozilla Firefox แล้ว คือHTTP Public Key Pinning (HPKP) เป็นกลไกที่ระบุว่าจะใช้ TLS Certificate ใดบ้าง ในการเชื่อมต่อเพื่อใช้งาน โดยจะรับรองผ่าน Certificate Authority เพียงเจ้าเดียว หรือหลายเจ้าก็ได้

รู้จัก HTTP Public Key Pinning (HPKP)

ขั้นตอนการทำงานของ HPKP คือตรวจสอบจากค่าแฮชของ TLS Certificate นั้น ว่าตรงกับที่ระบุไว้ใน HTTP Header ในครั้งแรกที่ได้เข้าใช้บริการนั้นหรือไม่ (เทคนิคที่ว่าคือ Trust on First Use หรือ TOFU) เพราะหลังจากได้ข้อมูลดังกล่าวแล้ว client จะเชื่อค่าแฮชนั้นบนระยะเวลาที่กำหนดไว้ และจะอัพเดตค่าแฮชใหม่อีกครั้ง หลังจากที่ระยะเวลาดังกล่าวสิ้นสุดลง หากในระหว่างนั้นค่าแฮชของ TLS Certificate มีการเปลี่ยนแปลงไปจากที่รับรู้มาก่อนหน้านี้ จะไม่เชื่อถือ TLS Certificate ดังกล่าว

2016-06-09_230144

วิธีการเปิดใช้งานคือ เพิ่ม header ที่ชื่อ Public-Key-Pins หรือ Public-Key-Pins-Report-Only เมื่อมีการเข้าถึงผ่าน HTTPS โดยมีรูปแบบในตัวข้อมูลดังต่อไปนี้

Public-Key-Pins: pin-sha256="base64=="; max-age=expireTime [; includeSubDomains][; report-uri="reportURI"]

Public-Key-Pins-Report-Only: pin-sha256="base64=="; max-age=expireTime [; includeSubDomains][; report-uri="reportURI"]

อธิบายโค้ดแต่ละส่วน

  • pin-sha256 required
    ชุดตัวอักษรแบบ Base64 ซึ่งแปลงจากชุดตัวอักษรแฮชแบบ SHA-256 โดยข้อมูลดังกล่าวได้จาก Subject Public Key Information (SPKI) fingerprint ของไฟล์ Private Key, ไฟล์ Certificate Signing Request หรือไฟล์ Certificate (ที่ได้จาก Certificate Authority)
    หมายเหตุ ในอนาคตอาจจะใช้ชุดตัวอักษรแฮชแบบอื่นๆ นอกจาก SHA-256 ก็ได้ ขึ้นอยู่กับมาตรฐานในอนาคต
  • max-age required
    ระยะเวลาที่บอก client ว่าจะจำค่าแฮชดังกล่าวไว้นานเท่าใดหน่วยเป็นวินาที
  • includeSubDomains Optional
    เป็นชุดพารามิเตอร์ที่ไว้ระบุว่าค่าแฮชดังกล่าวรวมถึง subdomain ด้วย
  • report-uri Optional
    เป็นชุดพารามิเตอร์ที่บอกว่าหากพบการตรวจสอบแล้วผิดพลาด ให้แจ้งไปยัง URL ที่ระบุไว้ โดยจะเป็นการ POST ชุดข้อมูลเป็น JSON ในรูปแบบต่อไปนี้

    {
         "date-time": date-time,
         "hostname": hostname,
         "port": port,
         "effective-expiration-date": expiration-date,
         "include-subdomains": include-subdomains,
         "noted-hostname": noted-hostname,
         "served-certificate-chain": [
           pem1, ... pemN
         ],
         "validated-certificate-chain": [
           pem1, ... pemN
         ],
         "known-pins": [
           known-pin1, ... known-pinN
         ]
    }

    ข้อมูลเพิ่มเติมอ่านต่อที่ Reporting Pin Validation Failure

จุดแตกต่างของ Public-Key-Pins และ Public-Key-Pins-Report-Only คือ

Public-Key-Pins จะตรวจสอบค่าแฮชของ TLS Certificate หากไม่ตรงตามที่กำหนดไว้จะไม่ยินยอมให้ client เข้าใช้งาน ถ้ามีการกำหนด report-uri ไว้ จะส่งรายงานไปยัง URL นั้น

Public-Key-Pins-Report-Only จะตรวจสอบค่าแฮชของ TLS Certificate หากไม่ตรงตามที่กำหนดไว้จะรายงานไปยัง URL ที่กำหนดไว้ที่ report-uri แต่ยังยินยอมให้ client เข้าใช้งาน

เมื่อทราบองค์ประกอบของตัวชุดข้อมูลบน HTTP header แล้ว ส่วนที่สำคัญคือชุดข้อมูล Base64 ที่จะใช้ใน pin-sha256 ซึ่งจะได้จากไฟล์ Private Key, ไฟล์ Certificate Signing Request หรือไฟล์ Certificate

ชุดคำสั่งที่จะได้ค่าดังกล่าวมานั้นมีดังนี้

1. ดึงค่า Base64 จาก Private Key

openssl rsa -in private.key -outform der -pubout | openssl dgst -sha256 -binary | openssl enc -base64

2. ดึงค่า Base64 จาก Certificate Signing Request

openssl req -in cert-signing-request.csr -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

3. ดึงค่า Base64 จาก Certificate

openssl x509 -in certificate.crt -pubkey -noout | openssl rsa -pubin -outform der | openssl dgst -sha256 -binary | openssl enc -base64

ตัวอย่างเมื่อรันคำสั่งตามข้างต้น จะได้ผลดังภาพด้านล่าง

2016-06-10_003753

ค่าที่ได้จะต้องเหมือนกันทั้ง 3 คำสั่ง แล้วนำเอาข้อมูลที่ได้ไปใส่ลงใน HTTP Header

ปรกติ ก่อนใช้ Public-Key-Pins มักจะทดสอบด้วย Public-Key-Pins-Report-Only ก่อน เพื่อไม่ให้เกิดการ block การใช้งานเกิดขึ้นหากกำหนดค่า pin-sha256 ผิดพลาด เมื่อทดสอบเสร็จแล้วจึงกำหนดค่า Public-Key-Pins อีกครั้ง แต่บางคนอาจจะกำหนด Public-Key-Pins แล้วปรับ max-age ไว้ไม่เยอะก็ได้ (ตรงนี้แล้วแต่สะดวก) แล้วจึงกำหนด max-age ที่มีระยะเวลายาวนาน 1-2 เดือน เป็นอย่างน้อยที่สุด

Public-Key-Pins: max-age=5184000; 
pin-sha256="C8XLmj2eoYs1gqjNksWfsIA89sIAKNraGspBaXU/l+4="; 
report-uri="https://thaicyberpoint.report-uri.io/r/default/hpkp/enforce"

Public-Key-Pins-Report-Only: max-age=5184000; 
pin-sha256="C8XLmj2eoYs1gqjNksWfsIA89sIAKNraGspBaXU/l+4="; 
report-uri="https://thaicyberpoint.report-uri.io/r/default/hpkp/reportOnly"

คำแนะนำเพิ่มเติม

การมีค่า pin-sha256 เพียงค่าเดียวกัน อาจจะมีปัญหาในช่วงที่ Certificate กำลังจะหมดอายุ หรือ Private Key ชุดเก่าหลุดจนเกิดปัญหา ทำให้ต้องมีการใช้ Private Key ชุดใหม่ เราจึงควรสร้าง Private Key สำรองเพื่อใช้สำหรับต่ออายุ Certificate หรือเหตุการณ์ที่ไม่คาดคิดในอนาคตไปสัก 2-3 ชุด แล้วใส่ค่า Base64 ของ Private Key ชุดดังกล่าวที่ยังไม่ได้ถูกใช้งานลงไปพร้อมกันด้วย

Public-Key-Pins: pin-sha256="pzel6nQW2KK7geOhEeaci3qEDf1TJeg7CNCFqU9RvkQ=";
pin-sha256="IlsUjvSKCiDJYyuVTifR07/qaIKCUn0ZK8z9mG1rAZ0=";
pin-sha256="Rlef6668r6l11a8M2Ahf46PqK0Q4q+vnk/aRUCU+PeM="; 
max-age=5184000;
report-uri="https://thaicyberpoint.report-uri.io/r/default/hpkp/enforce"

Public-Key-Pins-Report-Only: pin-sha256="pzel6nQW2KK7geOhEeaci3qEDf1TJeg7CNCFqU9RvkQ=";
pin-sha256="IlsUjvSKCiDJYyuVTifR07/qaIKCUn0ZK8z9mG1rAZ0=";
pin-sha256="Rlef6668r6l11a8M2Ahf46PqK0Q4q+vnk/aRUCU+PeM="; 
max-age=5184000;
report-uri="https://thaicyberpoint.report-uri.io/r/default/hpkp/reportOnly"

การใช้งาน HPHK ในเว็บเซิร์ฟเวอร์

พอได้ข้อมูลครบตามนี้ ก็เอาไปใส่ในเว็บเซิร์ฟเวอร์ โดยบทความจะยกตัวอย่าง 3 ตัว คือ Apache, Nginx และ IIS โดยขออ้างอิงเพียง Public-Key-Pins ส่วน Public-Key-Pins-Report-Only ก็ใส่ไปคล้ายๆ กัน ต่างกันแค่ชื่อเริ่มต้นเท่านั้น

  1. Apache – (ต้องเปิด mod_headers ด้วย) เพิ่มในส่วนของ Web Server config อาจจะใส่ในส่วนของ vhost ก็ได้
    Header always set Public-Key-Pins "pin-sha256=\"pzel6nQW2KK7geOhEeaci3qEDf1TJeg7CNCFqU9RvkQ=\";pin-sha256=\"IlsUjvSKCiDJYyuVTifR07/qaIKCUn0ZK8z9mG1rAZ0=\";pin-sha256=\"Rlef6668r6l11a8M2Ahf46PqK0Q4q+vnk/aRUCU+PeM=\"; max-age=5184000;report-uri=\"https://thaicyberpoint.report-uri.io/r/default/hpkp/enforce\""
  2. Nginx – (ต้องเปิด ngx_http_headers_module ด้วย) เพิ่มในส่วนของ Web Server config อาจจะใส่ในส่วนของ vhost ก็ได้
    add_header Public-Key-Pins 'pin-sha256="pzel6nQW2KK7geOhEeaci3qEDf1TJeg7CNCFqU9RvkQ=";pin-sha256="IlsUjvSKCiDJYyuVTifR07/qaIKCUn0ZK8z9mG1rAZ0=";pin-sha256="Rlef6668r6l11a8M2Ahf46PqK0Q4q+vnk/aRUCU+PeM=";max-age=5184000;report-uri="https://thaicyberpoint.report-uri.io/r/default/hpkp/enforce"';
  3. IIS – แก้ไขที่ Web.config
    <httpProtocol>
     <customHeaders>
     <add name="Public-Key-Pins" value="pin-sha256=&quot;pzel6nQW2KK7geOhEeaci3qEDf1TJeg7CNCFqU9RvkQ=&quot;;pin-sha256=&quot;IlsUjvSKCiDJYyuVTifR07/qaIKCUn0ZK8z9mG1rAZ0=&quot;;pin-sha256=&quot;Rlef6668r6l11a8M2Ahf46PqK0Q4q+vnk/aRUCU+PeM=&quot;;max-age=5184000;report-uri=&quot;https://thaicyberpoint.report-uri.io/r/default/hpkp/enforce&quot;" />
     </customHeaders>
    </httpProtocol>

เมื่อตั้งค่าต่างๆ เรียบร้อยแล้ว ลองทดสอบผ่านทาง SSL Server Test เพื่อดูผลว่าตัวทดสอบสามารถตรวจจับข้อมูลที่เราได้ตั้งค่าได้หรือไม่

2016-06-10_013750

2016-06-10_150936

โดยหากเจอปัญหาค่าแฮชที่ตรวจสอบไม่ตรงตามขั้นตอนข้างต้น จะขึ้นข้อความตามด้านล่างนี้ บน Google Chrome และ Mozilla Firefox (อาจจะเปลี่ยนแปลงไปบ้างในแต่ละรุ่นที่ออกมาในอนาคต)

hpkp_test_chrome

รูปจาก What is Public Key Pinning / HPKP ? 

รูปจาก About Public Key Pinning 

ส่วนในกรณีที่ใช้การเขียนซอฟต์แวร์สำหรับเชื่อมต่อผ่าน API นั้น เราสามารถใช้การตรวจสอบในลักษณะนี้ ในการตรวจสอบความน่าเชื่อถือของการเชื่อมต่อได้ด้วยการเขียนชุดคำสั่งตรวจสอบได้เช่นกัน ตัวอย่างเช่น Designing Evolvable Web APIs with ASP.NET – Chapter 15. Security โดยเราจะใช้ลักษณะ Trust on First Use ตามแบบเว็บเบราว์เซอร์ หรือจะใช้การบันทึกค่าแฮชของ TLS Certificate ไว้ในตัวซอฟต์แวร์ก็ได้ เพราะการพัฒนาซอฟต์แวร์ที่เราควบคุมสภาพแวดล้อมได้ หากบันทึกค่าแฮชไว้ภายในตัวซอฟต์แวร์ก็จะช่วยลดความเสี่ยงในเรื่อง Trust on First Use ได้

อะไรคือความเสี่ยงของ Trust on First Use?

คำตอบคือ หากในครั้งแรกที่เข้าใช้บริการ เครื่องที่เข้าใช้งานได้รับข้อมูลที่เป็นค่าแฮชปลอมบน HTTP Header ไปก่อนแล้ว วิธีการนี้ก็จะไม่สามารถตรวจสอบได้อีกต่อไปว่าจะเชื่อค่าแฮชชุดใดกันแน่ที่เป็นค่าแฮชจริง การใช้เทคนิค Trust on First Use จึงเป็นเพียงแค่ช่วยเพิ่มความสะดวกสำหรับคนใช้งานเบราว์เซอร์ทั่วไป

สุดท้าย ในปัจจุบัน (ณ วันที่ 10/6/2016) มีเบราว์เซอร์อย่าง Google Chrome และ Mozilla Firefox รองรับ และหวังว่าจะมีเบราว์เซอร์ตัวอื่นๆ ในอนาคตที่จะเพิ่มเติมการตรวจสอบนี้เข้ามาในตัวเบราว์เซอร์ น่าจะช่วยให้เราให้บริการกับลูกค้าได้ปลอดภัยมากขึ้น รวมไปถึงซอฟต์แวร์ต่างๆ ที่พัฒนาจะใช้การจดจำค่าแฮชเหล่านี้เป็นค่าเริ่มต้น เพื่อช่วยป้องกัน และควบคุมการใช้ TLS Certificate ที่เราเป็นผู้รับผิดชอบเองจริงๆ ไม่ใช่เกิดจากการสวมรอย หรือออก TLS Certificate ที่ผิดพลาดจาก Certificate Authority ที่เราไม่ได้ใช้บริการอยู่

อ้างอิงจาก