Certificate Pinning vs E2E Encryption

I see that there are some APIs which exchange some sort public keys to secure the content of https connection using asymmetric encryption. Is there any added benefit to this? As far as I know, it should be impossible to man in the middle a tls connection which have certificate pinning.

Leggi come funziona l'intero protocollo TLS, è un ottimo articolo disponibile qui: Come funziona SSL / TLS?

In poche parole le chiavi pubbliche vengono utilizzate per consentire l'autenticazione del contenuto crittografato mediante chiavi simmetriche (chiavi derivate come parte dell'handshake del protocollo).

Gli attacchi Man in the middle non vengono sempre mitigati a causa del blocco dei certificati. Ad esempio, se il browser non ha mai visitato il sito prima che un utente malintenzionato possa restituire il proprio certificato che non menziona nulla sul pinning.

The benefit of end to end encryption is clear when the content is sent from an end user to another end user, making the backend server unable to read it.

No. Protegge solo i dati in transito, quando arriva sul server qualsiasi cosa su quel server potrebbe in teoria vedere i dati.

But I have seen some example where it's just sending data to the backend (end client to end backend), but some kind of asymmetric encryption was applied.

For example AWS S3 allows client to encrypt data before sending it. I read somewhere that Akamai might also encrypt the content. I have also seen some institutions which needs to use their card/keys to encrypt the content.

S3 consente la crittografia asimmetrica lato client. Il che significa che il tuo computer locale sta crittografando i dati prima di inviarli ad AWS. Questo significa solo che tu, nemmeno AWS, puoi vedere il contenuto dei file. Questo serve per proteggere i dati a riposo, non i dati in transito.

So back to my question, is there actually any benefit of encrypting content using some means (either RSA, or some device), and sending it over TLS with certificate pinning?

Dipende dall'accettazione del rischio e dai requisiti di conformità. Ma sì, la crittografia dei dati non autentica i dati da sola. Se invii qualcuno a un file crittografato, come fanno a sapere che in realtà proviene da te? Qualcuno potrebbe aver usato la tua chiave. La crittografia SSL / TLS ma autentica anche la connessione, quindi sai che stai davvero "parlando" al punto finale in cui hai iniziato la comunicazione. Il blocco del certificato aggiunge la certezza che stai ottenendo lo stesso certificato che hai fatto l'ultima volta, e quindi meno probabilità di essere coinvolto in un uomo nell'attacco centrale.

Mi piace questo problema a livelli. TLS è il luogo in cui utilizziamo Pinning per garantire che ci si fidi solo di un certificato server specifico che è il più alto dei livelli (sessione / trasporto essenzialmente) e stiamo garantendo il non ripudio della coppia di chiavi del server. Per esempio. Sappiamo che la coppia di chiavi di cui ci fidiamo è la coppia di chiavi a cui ci stiamo connettendo e l'uso della tradizionale catena di trust (verificando le AC di firma). Si potrebbe dire che è irrilevante controllare la catena di un certificato bloccato, ma lo ignoreremo per ora in quanto non cambia significativamente il modello.

Il certificato stesso è richiesto dal servizio che fornisce la terminazione TLS per la sessione, nella maggior parte delle implementazioni al di fuori dello sviluppo / uso individuale spesso vediamo server Web / LB che terminano connessioni TLS che vivono separatamente dai server applicazioni che rispondono alle richieste dinamiche dagli utenti finali.

Il server / l'elaborazione delle applicazioni è il punto in cui i dati all'interno del tunnel TLS stanno andando, ma non è garantito che sia controllato dalla stessa persona / organizzazione che si sta fidando, bloccando il certificato. L'aggiunta di ulteriore crittografia al livello di sessione (sui dati stessi) può fornire ulteriore riservatezza se tale gruppo di chiavi viene controllato separatamente dal certificato del server TLS (ad esempio se si crittografano i dati utilizzando le proprie chiavi simmetriche).

Se si parla di crittografia asimmetrica, è possibile utilizzare una coppia di chiavi separata per garantire l'identità sul lato client (se il client ha una coppia di chiavi in cui l'aspetto pubblico è stato condiviso con il server di destinazione) è quindi possibile crittografare i dati utilizzando il proprio chiave privata per dimostrare il non ripudio di tu (che controlla il tuo certificato client) all'interno del tunnel TLS, consentendo la riservatezza della transazione e la non disconoscibilità del server, e dopo la verifica del non ripudio del cliente.