Hỏi SSL: Moi người cho mình hỏi, hiện tại mình thấy có 2 dạng handle SSL cho server:

Một là ở app level, ví dụ khi init một cái HTTP server thì chỉ định luôn SSL cert, ví dụ:

err := http.ListenAndServeTLS(“:443”, “server.crt”, “server.key”, nil)

Một cách khác là handle ở Nginx (về lý thuyết chắc nó cũng là app level nhỉ):

server { listen 443 ssl; server_name www.example.com; ssl_certificate www.example.com.crt; ssl_certificate_key www.example.com.key;

Còn dạng thứ hai là dùng SSL thông qua gateway provider như Cloudflare, hay Heroku.

Không biết ưu nhược điểm của từng cách trên là như thế nào nhỉ?

3 kiểu trên thật ra cũng là dạng 1 cái app nào đó load cert lên rồi handleshake client request thôi. Khác nhau chính là setup ở layer nào thôi

Khác nhau cách 1 và 2/3 là:

  • 1 là App level hoặc có thể hiểu là Business level
  • 2/3 là dạng proxy level. Lúc này proxy service (nginx/cloudflare,aws certificates + gateway) sẽ keep connection tới server bằng bất cứ kiểu gì, ko nhất thiết phải là https

Khác nhau cách 1/2 và 3 là:

  • Tự mình handle/configure
  • External provider service

Ưu nhược

  • Cách 1:
  • Ưu điểm:
    • Gọn, nhẹ, 1 binary/docker có thể có tất cả.
    • Không cần setup thêm service ngoài để làm ssl
    • Có thể custom code để làm nhiều trò theo ý thích
  • Nhược:
    • Mix giữa business level và connection level
    • Về căn bản thì nhiều business app không care tới ssl gì, allowanced domains support là gì, vì nó ko phải trách nhiệm của app
    • Renew invalid các kiểu manually. Hoặc nếu tự động thì phải có cơ chế expitre + re-load
    • Hạn chế khi share certificate, hoặc proxy 1 request vào nhiều app
  • Cách 2:
  • Ưu điểm: * Tách business level ra khỏi infra level * Dễ dàng setup 1 proxy nhiều ssl để routing nhiều app khác nhau * Dễ dàng setup 1 proxy 1 ssl để routing routing khác nhau * Khi cần thay thế/renew thì chỉ thay đổi/configure proxy level thôi, ko cần stop business level * Đa phần support hết case rồi, chỉ học cách configure thôi

  • Nhược điểm: * Phải setup service riêng để handle request trước khi nó vào app * Nếu làm mấy thứ phức tạp quá (VD build 1 cái proxy service đem bán) thì nhiều khi ko support hết, phải tự viết thêm * Phải học cách config nhiều để turning performance

  • Cách 3:
  • Ưu điểm:
    • Infra nhà người ta, mình ko cần mantain
    • Configure đễ hơn cách 2
    • Có nhiều món ăn kèm như chống ddos, cache bla bla mà ko cần setup/plugin thêm
    • External provider sẽ face ra internet chứ ko phải cụm server của mình. Nên nếu có gì sảy ra thì external provider sẽ bị tấn công chứ ko phải mình
  • Nhược điểm
    • Tiền khi nhu cầu vượt basic
    • Mình không quản lý/control hết tất cả
    • Phải setup cái flow hợp lý khi dev/test/prod
    • Không phải cái gì cũng như mình muốn, mà mình phải follow cái nó cung cấp

Source: webuild