SSL-TLS and SET

Remote transaction created some security issues:

• Problems of remoteness: trust factor between parties, use of sensitive data, atomicity of transaction
• Internet protocol problems: authentication and confidentiality, being sure about the website’s trustworthiness
• Transparence and critical mass problem: the website should be similar as secure as physical shops, but security is always a cost, usability should not be impaired

Two main protocols were proposed for this purpose: HTTP over SSL (Secure Socket Layer or HTTPS) or SET (Secure Electronic Transaction).

Definitions

• HTTPS (HTTP over SSL): a protocol designed to secure communication, not transactions. It guarantees confidentiality and integrity, while offering mutual authentication. It grants no guarantees on data usage, nor strict authentication of client.
• SET (Secure Electronic Transaction): a protocol designed for transaction security. It guarantees on data usage and transaction security enforcement. It failed to reach critical mass support to be applied.

SSL - Secure Socket Layer

SSL was originally designed by Netscape for securing internal web communication and, after some years, it became standard also for other protocols: IETF standardized TLS, which comes after version SSL v3, and is now at version 1.3. All previous versions to TLS 1.2 are considered unsafe.

Important

TLS enforces confidentiality and integrity of the communications, server authentication and optional client authentication, uses both symmetric encryption and asymmetric cryptography for performance reasons, in particular to reach a trade off between the algorithms’ computational costs and their performance.

If client and server want to perform a TLS handshake (to establish a HTTPS connection), the client will send the serve a cipher suite and some random data. Being TLS designed to be flexible with respect to technical evolution, it was built to manage the possibility of clients and servers using different suites of algorithms for different functions. It was designed to guarantee the connection even if clients and servers used different machines and this is cipher suite’s purpose: it is built to agree on the shared algorithm in order of preference. Clients and server may use different suites of algorithms for key exchange, bulk encryption, message authentication code, pseudorandom function. During handshake, cipher suites are compared to agree on shared algorithms in order of preference.

The client sends a list of algorithms divided by functionality and the server selects the first one compatible. The standard mandates implementation of a minimal cipher setting to guarantee connection in any case. The server will select the suite and send the client its cipher selection and some other random data together with the server certificate containing its public key. At this point the server certificate must be verified: is the certificate in the validity period? Is the root CA trusted? Is the certificate valid? Is it revoked? Is the name of the server in the certificate the same that was requested? Validity of the certificate and certification chain can always be checked while browsing the internet. If the certificate is valid the client can server the pre-master (first) secret, encrypted with server public key. An attacker cannot read it easily, because only the server (with its private key) can decrypt it. From this point on the exchanged information is encrypted. During this step the client can optionally send its client certificate (authenticate by signing with private key).

Now both client and server compute the shared secret from pre-master secret, using client random data and server random data. This real secret is used to create the encrypted channel for communication.

Client and server need to exchange random data to avoid replay attacks. But is TLS Resistant to MITM? MITM could:

• Let the original certificate through: needs to actually have the key of that certificate
• Tamper the certificate the server sends to the client, send a fake certificate (i.e., signed by a non-trusted CA): verification will fail
• Send a good certificate but substitute the public key (making it invalid): verification will fail

TLS is by design resistant to MITM attacks. The only step not under the control of the server is the certificate validation. If the certificate is not verified, the user will be warned, but the user might just ignore it (especially if the name looks valid and known). In this way, users will accept anything the attackers send. This mechanism is not resistant to users’ dumbness. Nowadays, there are more warnings to mitigate humans’ dumbness (e.g. advanced security settings). Besides, there are websites that use a mixture between HTTP and HTTPS, which are vulnerable to MITM attacks.

TLS basic features

• Protects transmissions: confidentiality and integrity
• Ensures authentication of server and client (optionally), if any of them is compromised however HTTPS fails to be secure
• No protection before or after transmission on server, client (e.g. Trojans), by abuser (e.g. non-honest merchant)
• Relies on PKI
• Not foolproof

A vanilla application proxy cannot filter/validate anything that is encrypted. To make the proxy able to decrypt stuff, a MITM must be added, so that the server connects via HTTPS to the proxy and the proxy connects via HTTPS to the client. A major issue is that the attacker can see the cipher selection (shared in clear) and thus change it: if it contains vulnerable algorithms and the attackers obliges to choose them connection is hijacked.

TLS’s drawbacks are related to its reliance on PKI (Public Key Infrastructure):

• Security guarantees of TLS depend on the security and trust of the root and intermediate CAs
• CAs can generate certs for any domain, they are responsible for domain validation
• In order to be included in browsers and OS root programs, CAs must abide to a set of requirements (CA/Browser Forum baseline requirements): dropping a non-compliant CA is a very difficult decision as it breaks websites

To overcome TLS/PKI limitations various solutions were proposed over time:

• HSTS (HTTP Strict Transport Security): a HTTP header tells the browser to always connect to that domain using HTTPS, browsers (e.g., Chrome) implement a HSTS preload list, some websites are simply never loaded over plain HTTP (defends against SSL stripping)
• HPKP (HTTP Public Key Pinning): a HTTP header tells the browser to “pin” a specific certificate or a specific CA, browser will refuse certificates from different CAs for that origin (defends against trust certificates mis-issuance), however it was deprecated because it was not scalable
• Certificate Transparency: a CA submits the metadata of every issued certificate to an independent, replicated log, it can be enforced by browsers which refuse certificates not logged in CA logs (defends against certificate miss issuance: site owner can check or be notified of certificates issued for the properties they manage), this is the method currently adopted (crt.sh to check)

SET - Secure Electronic Transaction

SET was developed thanks to the joint effort of VISA and MasterCard consortium with the main purpose of protecting transactions, not connections. It was designed considering that the cardholder sends the merchant only the order of goods and sends the payment data to the payment gateway which will accept or reject the transaction. The gateway is empowered to verify correspondence. This is done with a dual signature, a signature that joins together the two pieces of a message, directed to two distinct recipients.

graph LR
subgraph "Generation of Dual Signature"

        A[Order Information] -->|hash function| B[hash1]

        C[Payment Instructions] -->|hash function| D[hash2]

        B --> E[hash function]

        D --> E[hash function]

        E[dual hash] -->|sign with cardholder private key| F[dual signature]

    end
   style A stroke:#ff0000,stroke-width:2px;

    style B stroke:#ff0000,stroke-width:2px;

    style C stroke:#0000ff,stroke-width:2px;

    style D stroke:#0000ff,stroke-width:2px;

    style E stroke:#00ff00,stroke-width:2px;

    style F fill:#ffa500,stroke:#333,stroke-width:4px;

    

First of all, the order information and payment instructions are hashed and their result is hashed again (dual hash). Then the dual hash is encrypted and the dual signature is generated. The payment gateway side verification is the perfect dual.

graph LR
subgraph "Data Transmission"

        subgraph OI["Order Information"]

        G[Order Information] --- H[hash2]

        G --- I[dual sign.]

        end

        OI -->|encrypt with public key of merchant| J>Order Information encrypted]

        subgraph PI["Payment Instruction"]

        K[Payment Instructions] --- L[hash1]

        K --- M[dual sign.]

        end

        PI -->|encrypt with public key of payment gateway| N>Payment Instructions encrypted]

        J --- O((Order))

        N --- O

  

        subgraph PIG["Payment information for the Gateway ~ still encrypted"]

            P[Payment Instructions] --- Q[hash1]

            P --- R[dual sign.]

        end

  

        O --- PIG --- S((🏦))

    end
style G stroke:#ff0000,stroke-width:2px;

    style H stroke:#ff0000,stroke-width:2px;

    style I fill:#ffa500,stroke:#333,stroke-width:2px;

    style J fill:#ccc,stroke:#333,stroke-width:2px;

    style K stroke:#0000ff,stroke-width:2px;

    style L stroke:#0000ff,stroke-width:2px;

    style M fill:#ffa500,stroke:#333,stroke-width:2px;

    style N fill:#ccc,stroke:#333,stroke-width:2px;

    style Q stroke:#0000ff,stroke-width:2px;

    style P stroke:#0000ff,stroke-width:2px;

    style R fill:#ffa500,stroke:#333,stroke-width:2px;

graph TD

    subgraph "Verification Phase (Merchant Side)"

        S[Order Information] -->|hash function| T[hash1]

        S -->|hash function| U[hash2]

        T --> V[hash function]

        U --> V[hash function]

        F[dual signature] -->|verify with public key of cardholder| V[dual hash]

    end

    style S stroke:#ff0000,stroke-width:2px;

    style T stroke:#ff0000,stroke-width:2px;

    style U stroke:#0000ff,stroke-width:2px;

    style V stroke:#00ff00,stroke-width:2px;

SET method however failed, mainly because it requires digital certificates from merchant (reasonable and feasible), payment Gateway (reasonable and feasible), cardholder: does not scale, a pre-registration of the cardholder is needed. Being not transparent, it was not accepted by average users which do not use it. A similar mechanism now used for transactions is Paypal. Nowadays, a simple redirect with a token to the website of the bank is commonly used.