TLS/SSL – @FordAntiTrust

แนะนำการใช้ HTTP Strict Transport Security (HSTS) เพื่อให้เว็บเบราว์เซอร์ติดต่อผ่านช่องทางเข้ารหัสเท่านั้น

October 6, 2022May 24, 2019 by @FordAntiTrust

ไม่ได้เขียนเรื่องเทคโนโลยีมานาน รอบนี้เป็นบทความที่ดองมานานมาก รอบนี้เป็นบทความที่ต่อจากเรื่อง HTTP Public Key Pinning (HPKP) เพื่อป้องกัน Certification Authority ออก TLS Certificate ซ้ำซ้อน ที่เขียนไปก่อนหน้านี้

โดย HTTP Strict Transport Security (ต่อไปจะเรียกว่า HSTS) เป็นการเพิ่มประสิทธิภาพในรักษาความปลอดภัย เพื่อบอกให้เว็บเบราว์เซอร์ที่กำลังเข้ามาใช้บริการเว็บไซต์ ต้องทำงานผ่านช่องทางเข้ารหัส Hypertext Transfer Protocol Secure เท่านั้น (ต่อไปจะเรียกว่า HTTPS)

โดยจะเพิ่มชุดคำสั่งด้านล่างลงใน HTTP Header เพื่อส่งไปบอกเว็บเบราว์เซอร์

Strict-Transport-Security: max-age=expireTime [; includeSubDomains][; preload]

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

max-age required
ระยะเวลาที่บอก client ว่าจะให้จำว่าควรเข้าเว็บผ่านช่องทางเข้ารหัส HTTPS นานเท่าใด โดยหน่วยเป็นวินาที
includeSubDomains Optional
ระบุว่าการใช้งาน HSTS ดังกล่าวรวมถึง subdomain ด้วย
preload Optional
หากในตัว domain ข้างต้น มีการเรียกใช้ข้อมูลใด ๆ ที่โหลดมาจาก domain ที่อยู่ในรายการ HSTS preload service บน browser ให้ใช้การเชื่อมต่อผ่านช่องทางเข้ารหัส HTTPS เช่นกัน โดย HSTS preload service นี้ Google เป็นคนดูแลรายชื่อ domain ดังกล่าวผ่าน https://hstspreload.org ซึ่งตอนนี้มี Browser อย่าง Chrome, Firefox, Opera, Safari, IE 11 และ Edge ที่ใช้รายการ domain ดังกล่าวใส่ลงใน browser ตัวเอง ซึ่งมักถูกแนะนำให้ใช้เสมอหากเราใช้ 3rd party อย่าง Javascript หรือ CSS ที่โหลดผ่าน CDN ต่าง ๆ

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

พอได้ข้อมูลครบตามนี้ ก็เอาไปใส่ในเว็บเซิร์ฟเวอร์ โดยบทความจะยกตัวอย่าง 4 ตัว คือ Apache, Nginx, IIS และ .NET Core

Apache – (ต้องเปิด mod_headers ด้วย) เพิ่มในส่วนของ Web Server config อาจจะใส่ในส่วนของ vhost ก็ได้

Header always set Strict-Transport-Security: max-age=31536000

หรือหากมีเพิ่มพารามิเตอร์

Header always set Strict-Transport-Security: max-age=31536000; includeSubDomains

Nginx – (ต้องเปิด ngx_http_headers_module ด้วย) เพิ่มในส่วนของ Web Server config อาจจะใส่ในส่วนของ vhost ก็ได้

add_header Strict-Transport-Security: max-age=31536000

หรือหากมีเพิ่มพารามิเตอร์

add_header Strict-Transport-Security: max-age=31536000; includeSubDomains

IIS – แก้ไขที่ Web.config

<httpProtocol>
 <customHeaders>
 <add name="Strict-Transport-Security" value="max-age=31536000" />
 </customHeaders>
</httpProtocol>

หรือหากมีเพิ่มพารามิเตอร์

<httpProtocol>
 <customHeaders>
 <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains" />
 </customHeaders>
</httpProtocol>

ASP.NET Core 2.1 หรือมากกว่า เพิ่มเติมดังนี้

public void Configure(IApplicationBuilder app, IHostingEnvironment env)
{
    ...
    app.UseHsts();
    ...
}

การแก้ไขพารามิเตอร์ทำผ่าน method ชื่อ ConfigureServices ได้ตามด้านล่าง

public void ConfigureServices(IServiceCollection services)
{
    ...
    services.AddHsts(options =>
    {
        options.Preload = true;
        options.IncludeSubDomains = true;
        options.MaxAge = TimeSpan.FromDays(365);
    });
    ...
}

จากข้อมูลการใช้งาน และตัวอย่างทั้งหมด การเพิ่มเติมดังกล่าวมีประโยชน์ในการช่วยให้ผู้ใช้งาน เข้าเว็บผ่าน HTTPS ได้ปลอดภัยขึ้น หากในครั้งแรกที่เข้าเว็บได้รับ HTTP Header ข้างต้นอย่างถูกต้อง ในครั้งต่อไปตัวเว็บเบราว์เซอร์จะเข้าผ่าน URL protocal “https://” ทันที โดยไม่ต้องผ่าน “http://” อีก ทำให้ลดการถูก man-in-the-middle attacker เพื่อดังฟังข้อมูลอื่น ๆ ระหว่างการเปลี่ยนผ่านจาก URL protocal “http://” ไปยัง “https://” ได้ รวมไปถึงการโดน intercept traffic เพื่อให้เรารับ Certificate ที่ไม่ถูกต้องระหว่างการเข้าถึงหน้า HTTPS ได้

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

October 6, 2022June 10, 2016 by @FordAntiTrust

กระบวนการรับรอง 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 สำหรับโดเมนของกูเกิลได้สำเร็จ, ทุกเว็บของกูเกิลเสี่ยงต่อการถูกดักฟัง) หรือ กูเกิลเตือนใบรับรองดิจิทัลปลอมจากอินเดีย มาแล้ว

รูปจาก 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 ก็ยังไม่รองรับเป็นการทั่วไปสักเท่าไหร่

แต่ก็ยังมีวิธีที่ง่ายกว่า และมีการรองรับโดยเบราว์เซอร์เจ้าใหญ่อย่าง 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 ดังกล่าว

วิธีการเปิดใช้งานคือ เพิ่ม 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

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

ค่าที่ได้จะต้องเหมือนกันทั้ง 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 ก็ใส่ไปคล้ายๆ กัน ต่างกันแค่ชื่อเริ่มต้นเท่านั้น

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\""

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"';

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 เพื่อดูผลว่าตัวทดสอบสามารถตรวจจับข้อมูลที่เราได้ตั้งค่าได้หรือไม่

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

รูปจาก 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 ที่เราไม่ได้ใช้บริการอยู่

อ้างอิงจาก

Public Key Pinning Extension for HTTP – Internet Engineering Task Force (IETF)
Public Key Pinning – MDN
What is Certificate Transparency? How It helps Detect Fake SSL Certificates – The Hacker News

ตรวจสอบ favicon ให้ดี อาจมีการใช้ favicon เพื่อทำให้เข้าใจผิดว่ากำลังใช้ https ที่มีใบรับรองที่ถูกต้อง

October 6, 2022June 9, 2016 by @FordAntiTrust

อ่านข่าวเรื่องอัพเดท Firefox 47 บน Android แล้วเอา favicon ออกจาก address bar เลยสนใจว่าเรื่องนี้ว่าเอาออกทำไม

อธิบายก่อนว่า favicon หรือ favourite icon เป็นรูปขนาดเล็ก (ไอคอน) ที่มักแสดงอยู่ แถวๆ URL ของเว็บ หรือเดี่ยวนี้คงไว้ใกล้ๆ กับหัวข้อเว็บกัน (title bar) ตามภาพด้านล่าง

รูปนำมาจาก นำมาจาก https://css-tricks.com/favicon-quiz/

พอมาดูใน Firefox รุ่นบน Android และตำแหน่งที่ไว้ favicon ก็เข้าใจประเด็นว่าทำไมถึงต้องนำออกไป ตามภาพด้านล่าง

รูปนำมาจาก https://blog.mozilla.org/blog/2016/06/07/tab-video-improvements/

นั้นแสดงว่ามีรายงานว่าการไว้ favicon ตรงนั้น น่าจะถูกนำไปใช้ประโยชน์ในการหลอกผู้ใช้ว่าเว็บใช้ SSL/HTTPS ที่ปลอดภัยอยู่ (ซ้ำราย บนมือถือมักตรวจสอบ SSL/TLS fingerprint ได้ยาก iOS นี่เช็คไม่ได้เลย) ซึ่งใน browser เก่าๆ หรือบนมือถือที่มีพื้นที่จอจำกัด มักเอามาไว้ใกล้ๆ กัน หรือแสดงผลสลับกันตอนเปลี่ยน tab ทำให้สับสน ซึ่งประเด็นนี้ใน browser อื่นๆ เราก็ควรจะใส่ใจเช่นเดียวกัน เพราะบางครั้งก็สร้างความสับสนได้มากเช่นกัน (ตัวอย่างตามภาพท้ายเนื้อหา)

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

DNSSEC และ DANE ช่วยป้องกันการโดน Pharming และป้องกันการออก Certficate ปลอมหรือซ้ำซ้อน

October 6, 2022May 10, 2015 by @FordAntiTrust

การทำ DNSSEC ช่วยป้องกันการโดน Pharming (หรือเรียก DNS spoofing หรือ DNS cache poisoning) เพราะเป็นการ signed ตัว DNS Server ที่ใช้งานคู่กับ domain name ที่จดกับผู้รับจด domain เวลาตรวจสอบคำตอบที่ Resolver จะเช็คว่ามาจาก Name server ตัวจริงหรือไม่ ช่วยให้การได้รับ IP ส่งให้ client มีความถูกต้องเสมอ (ทดสอบแบบง่ายๆ คือแก้ไขไฟล์ hosts บนเครื่องให้วิ่งไปอีกเครื่องหนึ่งที่มีข้อมูลเหมือนกันทุกประกาศ ทำตัวเหมือนโดน trojan มาเปลี่ยนบนเครื่องให้ไปเครื่องปลอมเพื่อหลอกเอาข้อมูล)

สำหรับการทำ DANE ป้องกันการถูก fake certificate หรือเจอ Certification Authority ออกใบ certificate ซ้ำซ้อน เพราะเราจะเอา fingerprint ของ certificate ใส่ลงใน TLSA record บน DNS Server ทำให้ตอนตัว browser เรียกเว็บ จะมีการตรวจสอบว่า certificate ที่ได้มา มี fingerprint ตรงกับที่อยู่ใน TLSA record หรือไม่

ซึ่งทั้งสองอย่างยังไม่ค่อยเจอเว็บทั่วไปทำสักเท่าไหร่ และ browser ทั้ง 3 อันดับแรก ถ้าไม่ลง plugins ก็ยังตรวจสอบไม่ได้ครับ แต่เชื่อว่าอีกสักพักคงทยอยค่อยๆ ปรับกันมาแล้ว และเว็บในไทยที่เท่าที่เจอยังไม่ค่อยมีใครทำขนาด Google, Facebook, Micorosft ยังไม่ทำเลย

การทำให้เว็บรองรับ DNSSEC และ DANE ช่วยเพิ่มระบบในการป้องกันการที่ผู้ใช้งานเข้าใช้บริการของเว็บต่างๆ ได้ปลอดภัยมากขึ้นจากการทำ Man-in-The-Middle attacks ได้

วิดีโออธิบายการทำงานของ DNSSEC และ DANE

Tutorial on DANE and DNSSEC

ตัวอย่างเว็บที่ implement DNSSEC หรือ DANE

อ้างอิง

บั๊ก Heartbleed และความใส่ใจต่อการใช้ TLS/SSL ในเว็บคนไทย

October 6, 2022April 15, 2014 by @FordAntiTrust

ว่ากันตามจริง เว็บคนไทยส่วนใหญ่ไม่ได้รับผลกระทบจากบั๊ก Heartbleed กันเสียเท่าไหร่นัก เพราะ “ส่วนใหญ่ไม่ใช้ TLS/SSL” ซึ่งแม้แต่เว็บอันดับต้นๆ ของไทยเท่าที่ตรวจสอบก็ไม่ได้ใช้แม้จะมีการรับ-ส่งข้อมูลสำคัญเช่น ชื่อสมาชิก และรหัสผ่าน อย่าเป็นเรื่องปรกติ

ในความคิดเห็นส่วนตัวแล้วอยากให้มีการออกประกาศ เพื่อสร้างความใส่ใจต่อการคุ้มครองข้อมูลส่วนตัวว่า “เว็บไทยที่มีการรับข้อมูลที่สำคัญ จำพวกชื่อสมาชิก และรหัสผ่าน ควรใช้ TLS/SSL ในการติอต่อสื่อสารข้อมูลอย่างยิ่ง” เพราะเว็บคนไทยเราน้อยมากที่จะใช้ TLS/SSL ซึ่งหากเว็บที่ไม่ได้ใช้ TLS/SSL ในขั้นตอนการรับ-ส่งข้อมูลสำคัญเหล่านั้นเป็นปัญหาที่หนักหนาสาหัสกว่าบั๊กของ Heartbleed มากนัก เพราะปัญหาบั๊ก Heartbleed นั้นตั้งถูกตั้งบนสมมติฐานว่า private key อาจจะถูกขโมยไป ทำให้การดักฟังข้อมูลระหว่างเว็บและสมาชิกที่สื่อสารบน TLS/SSL ถูกดักฟังได้จากการใช้ private key ที่ถูกขโมยไปนำมาถอดรหัสเพื่อดักฟัง แต่เว็บที่ไม่มี TLS/SSL เพื่อบริการให้กับสมาชิกโดยป้องกันการถูกดักฟังนั้น คนดักฟังไม่ต้องสนใจว่าจะหาอะไรมาถอดรหัสออดแต่อย่างใด เพราะข้อมูลที่สื่อสารไปมานั้นมันเปลื่อยโล่งทั้งหมด ใครดักฟังก็เห็นได้ทันที และมันเป็นปัญหาที่ใหญ่กว่ามาก

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

หมายเหตุเพิ่มเติม: Heartbleed เป็นบั๊กที่เป็นข้อผิดพลาดของซอฟต์แวร์สำหรับการติดต่อสื่อสารที่ชื่อ OpenSSL ซึ่งเป็นเพียงซอฟต์แวร์ยอดนิยมสูงมากตัวหนึ่งในกลุ่มใช้ open souce software ที่ใช้เป็นมาตรฐานสำหรับการติดต่อสื่อสารแบบ TLS/SSL ซึ่งมีผลกระทบต่อระบบที่ใช้งาน TLS/SSL เป็นวงกว้างมาก แต่กระนั้นในตลาดก็ยังมีซอฟต์แวรเข้ารหัสในรูปแบบเดียวกันตัวอื่นๆ ที่ไม่ได้รับผลกระทบเช่นระบบ IIS ของ Microsoft (ที่ธนาคารไทยส่วนใหญ่ใช้) หรือซอฟต์แวร์เข้ารหัสการสื่อสารตัวอื่นๆ ที่ไม่ได้ใช้ OpenSSL เป็นตัวเข้ารหัสการติดต่อสื่อสารด้วย TLS/SSL