🐝
Mess around software system design
  • README
  • ArchitectureTradeOffAnalysis
    • Estimation
    • Middleware
    • Network
    • Server
    • Storage
  • Conversion cheat sheet
  • Scenarios
    • TinyURL
      • Estimation
      • Flowchart
      • Shortening mechanisms
      • Rest API
      • Performance
      • Storage
      • Follow-up
    • TaskScheduler
      • JDK delay queue
      • Timer based
      • RabbitMQ based
      • Kafka-based fixed delay time
      • Redis-based customized delay time
      • MySQL-based customized delay time
      • Timer TimingWheel
      • Industrial Scheduler
      • Workflow Engine
      • Airflow Arch
    • GoogleDrive
      • Estimation
      • Flowchart
      • Storage
      • Follow-up
    • Youtube
      • Estimation
      • Flowchart
      • Performance
      • Storage
      • Follow-up
      • Netflix
    • Uber
      • Estimation
      • Rest api
      • Flowchart
      • KNN algorithms
      • Geohash-based KNN mechanism
      • Redis implementation
      • Storage
    • Twitter
      • Estimation
      • Flowchart
      • Storage
      • Scalability
      • Follow-up
    • Instant messenger
      • Architecture overview
      • Presence
      • Unread count
      • Notifications
      • Read receipt
      • Large group chat
      • Storage-Offline 1:1 Chat
      • Storage-Offline group chat
      • Storage-Message roaming
      • NonFunc-Realtime
      • NonFunc-Reliability
      • NonFunc-Ordering
      • NonFunc-Security
      • Livecast-LinkedIn
    • Distributed Lock
      • Single machine
      • AP model based
      • CP model based
      • Chubby-TODO
    • Payment system
      • Resilience
      • Consistency
      • Flash sale
    • Key value store
      • Master-slave KV
      • Peer-to-peer KV
      • Distributed cache
  • Time series scenarios
    • Observability
      • TimeSeries data
      • Distributed traces
      • Logs
      • Metrics
      • NonFunc requirments
  • Search engine
    • Typeahead
    • Search engine
    • Distributed crawler
      • Estimation
      • Flowchart
      • Efficiency
      • Robustness
      • Performance
      • Storage
      • Standalone implementation
      • Python Scrapy framework
    • Stream search
  • Big data
    • GFS/HDFS
      • Data flow
      • High availability
      • Consistency
    • Map reduce
    • Big table/Hbase
    • Haystack
    • TopK
    • Stateful stream
    • Lambda architecture
    • storm架构
    • Beam架构
    • Comparing stream frameworks
    • Instagram-[TODO]
  • MicroSvcs
    • Service Registry
      • Flowchart
      • Data model
      • High availability
      • Comparison
      • Implementation
    • Service governance
      • Load balancing
      • Circuit breaker
      • Bulkhead
      • Downgrade
      • Timeout
      • API gateway
      • RateLimiter
        • Config
        • Algorithm comparison
        • Sliding window
        • Industrial impl
    • MicroSvcs_ConfigCenter-[TODO]
    • MicroSvcs_Security
      • Authentication
      • Authorization
      • Privacy
  • Cache
    • Typical topics
      • Expiration algorithm
      • Access patterns
      • Cache penetration
      • Big key
      • Hot key
      • Distributed lock
      • Data consistency
      • High availability
    • Cache_Redis
      • Data structure
      • ACID
      • Performance
      • Availability
      • Cluster
      • Applications
    • Cache_Memcached
  • Message queue
    • Overview
    • Kafka
      • Ordering
      • At least once
      • Message backlog
      • Consumer idempotency
      • High performance
      • Internal leader election
    • MySQL-based msg queue
    • Other msg queues
      • ActiveMQ-TODO
      • RabbitMQ-TODO
      • RocketMQ-TODO
      • Comparison between MQ
  • Traditional DB
    • Index data structure
    • Index categories
    • Lock
    • MVCC
    • Redo & Undo logs
    • Binlog
    • Schema design
    • DB optimization
    • Distributed transactions
    • High availability
    • Scalability
    • DB migration
    • Partition
    • Sharding
      • Sharding strategies
      • Sharding ID generator overview
        • Auto-increment key
        • UUID
        • Snowflake
        • Implement example
      • Cross-shard pagination queries
      • Non-shard key queries
      • Capacity planning
  • Non-Traditional DB
    • NoSQL overview
    • Rum guess
    • Data structure
    • MySQL based key value
    • KeyValueStore
    • ObjectStore
    • ElasticSearch
    • TableStore-[TODO]
    • Time series DB
    • DistributedAcidDatabase-[TODO]
  • Java basics
    • IO
    • Exception handling
  • Java concurrency
    • Overview
      • Synchronized
      • Reentrant lock
      • Concurrent collections
      • CAS
      • Others
    • Codes
      • ThreadLocal
      • ThreadPool
      • ThreadLifeCycle
      • SingletonPattern
      • Future
      • BlockingQueue
      • Counter
      • ConcurrentHashmap
      • DelayedQueue
  • Java JVM
    • Overview
    • Dynamic proxy
    • Class loading
    • Garbage collection
    • Visibility
  • Server
    • Nginx-[TODO]
  • Distributed system theories
    • Elementary school with CAP
    • Consistency
      • Eventual with Gossip
      • Strong with Raft
      • Tunable with Quorum
      • Fault tolerant with BFT-TODO
      • AutoMerge with CRDT
    • Time in distributed system
      • Logical time
      • Physical time
    • DDIA_Studying-[TODO]
  • Protocols
    • ApiDesign
      • REST
      • RPC
    • Websockets
    • Serialization
      • Thrift
      • Avro
    • HTTP
    • HTTPS
    • Netty-TODO
  • Statistical data structure
    • BloomFilter
    • HyperLoglog
    • CountMinSketch
  • DevOps
    • Container_Docker
    • Container_Kubernetes-[TODO]
  • Network components
    • CDN
    • DNS
    • Load balancer
    • Reverse proxy
    • 云中网络-TODO
  • Templates
    • interviewRecord
  • TODO
    • RecommendationSystem-[TODO]
    • SessionServer-[TODO]
    • Disk
    • Unix philosophy and Kafka
    • Bitcoin
    • Design pattern
      • StateMachine
      • Factory
    • Akka
    • GoogleDoc
      • CRDT
Powered by GitBook
On this page
  • Structure
  • How does TLS offer security
  • Confidentiality
  • Authentication
  • Integrity
  • TLS protocol (v1.2)
  • Overall flowchart
  • Components
  • TLS Handshake based on RSA
  • TLS Handshake based on ECDHE
  • TLS protocol (v1.3) Optimization

Was this helpful?

  1. Protocols

HTTPS

PreviousHTTPNextNetty-TODO

Last updated 3 years ago

Was this helpful?

Structure

  • Secure Sockets Layer / Transport layer security

  • Fifth layer. Netscape 1994. V2/V3

  • Versions:

    • SSLv1/v2

    • SSLv3.1 => TLS1.0

    • TLS1.0/1.1、SSLv3/v2 all considered to be unsecure

  • Most widely used: TLS 1.2

  • SSL/TLS could also be applied to other applications

    • FTP => FTPS

    • LDAP => LDAPS

How does TLS offer security

Confidentiality

  • A cipher suite is negotiated using TLS handshake and PKI is used to shared the secret key.

Symmetric encryption

  • RC4, DES, 3DES, AES, ChaCha20

  • Cons:

    • Does not have a reliable way to transfer cipher key

Asymmetric encryption

  • DH, DSA, RSA, ECC

PKI

  • First use RSA/ECDHE to solve the problem of exchanging private key

  • Generate session key used for symmetric key

// Speed comparison for symmetric asymetric
aes_128_cbc enc/dec 1000 times : 0.97ms, 13.11MB/s

rsa_1024 enc/dec 1000 times : 138.59ms, 93.80KB/s
rsa_1024/aes ratio = 143.17

rsa_2048 enc/dec 1000 times : 840.35ms, 15.47KB/s
rsa_2048/aes ratio = 868.13

Authentication

  • The identification is based on chain of trust and certificate authorities.

Digital signature

  • Reverse the usage of private and public key inside asymmetric encryption

  • Private key only encrypts the digest of message

Certificate

Certificate authority

  • Certificate authority

  • Certificate issuer: DigiCert, VeriSign, Entrust, Let's Encrypt

  • Types of certificates:

    • DV

    • EV

  • Root CA needs to have a self-signed certificate / root certificate.

Cons

  • What if CA gets tricked to issue certificate to the wrong person

    • CRL (certificate revocation list)

    • OCSP (online certificate status protocol)

  • CA itself get hacked

  • RSA asymmetric

Integrity

  • Whenever a TLS record is sent, a MAC value is generated and appended with each message.

  • Digest algorithm

    • MD5, SHA1-> SHA2 (SHA224, SHA256 and SHA384 could generate 28 bytes, 32 bytes and 48 bytes digests, correspondingly)

TLS protocol (v1.2)

Overall flowchart

  • TLS Cipher suite

    • key exchange algo - signature algo - symmetric encryption algo - digest algo

    • ECDHE-RSA-AES256-GCM-SHA384

  • Many softwares such as Nginx/Apache use OpenSSL to implement TLS

Components

  • Record protocol

    • Defines the basic unit for data transfer

  • Alert protocol

    • Send an alerting message to the other party

  • Change cipher spec protocol

    • States that all following conversations will be conducted in encrypted version

  • Handshake protocol

    • See the next section for details

TLS Handshake based on RSA

  • Process

    1. The client generates a symmetric key, encrypts it with the server's public key.

    2. Clients sends it to the server to use as the symmetric key for the established session.

    3. The server uses its private key to decrypt the sent symmetric key and the key-exchange is complete.

    4. Client and server could use the negotiated symmetric key to encrypt their session.

  • Weakness:

    • The same public-private key pair is used both to authenticate the server and to encrypt the symmetric session key sent to the server. As a result, if an attacker gains access to the private key and listens in on the exchange, then it could decrypt the entire session.

    • if an attacker does not currently have access to the private key, they can still record the encrypted session and decrypt it at a later time once they obtain the private key.

TLS Handshake based on ECDHE

  • Improvement compared with RSA:

    • Allow the client and server to negotiate a shared secret without explicitly communicating it in the handshake: The server's private key is used to sign and verify the handshake, but the established symmetric key never leaves the client or server and cannot be intercepted by a passive attacker even if they have access to the private key.

    • Diffie-Hellman key exchange can also be used to reduce the risk of compromise of past communication sessions.

    • TLS False Start: Client could send out request without waiting for server to reply with "Finished"

    • Will generate a new public/private key each time having a handshake. So even when one time's pre-master get deciphered, all previous conversation could stay safe.

  • "Hello" exchange random number, "Key exchange" exchange "pre-master".

  • Before "Change Cipher Spec", all plaintext; After all ciphertext.

  • Pre-Master must be transmitted in secret.

  • TCP handshake first

  • Client Hello

    • TLS version

    • Client random

    • Cipher suites (e.g. ECDHE_RSA)

Handshake Protocol: Client Hello
    Version: TLS 1.2 (0x0303)
    Random: 1cbf803321fd2623408dfe…
    Cipher Suites (17 suites)
        Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
        Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
  1. Server Hello:

    • TLS version

    • Server random

    • Cipher suites

Handshake Protocol: Server Hello
    Version: TLS 1.2 (0x0303)
    Random: 0e6320f21bae50842e96…
    Cipher Suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (0xc030)
  1. Server key exchange:

    • Server params

Handshake Protocol: Server Key Exchange
    EC Diffie-Hellman Server Params
        Curve Type: named_curve (0x03)
        Named Curve: x25519 (0x001d)
        Pubkey: 3b39deaf00217894e...
        Signature Algorithm: rsa_pkcs1_sha512 (0x0601)
        Signature: 37141adac38ea4...
  1. Client key exchange

    • Client params

Handshake Protocol: Client Key Exchange
    EC Diffie-Hellman Client Params
        Pubkey: 8c674d0e08dc27b5eaa…
  1. Now the Client has Client Params, Server Params, from which they will be able to compute PreMaster

  2. Using Client Random, Server Random and PreMaster, client and server will compute Master Secret.

  3. Client sends Change cipher spec.

  4. Client sends Finished.

  5. Server sends Change cipher spec.

  6. Server sends Finished.

TLS protocol (v1.3) Optimization

  • OSCP Stapling

  • TLS compression

  • TLS false start

  • Session resumption

  • Early termination

Structure
How does TLS offer security
Confidentiality
Authentication
Integrity
TLS protocol (v1.2)
Overall flowchart
Components
TLS Handshake based on RSA
TLS Handshake based on ECDHE
TLS protocol (v1.3) Optimization
HTTP stack
Security protocols
Symmetric encryption
Asymmetric encryption
PKI
digital signature
Certificate authority
Flow chart
TLS components