Ho letto su SSL / TLS e sono rimasto sorpreso quando ho visto le quantità di implementazioni SSL / TLS esistenti. wikipedia .
Quindi, c'è davvero bisogno di tutte queste diverse implementazioni?
Non sarebbe più economico, più produttivo e più veloce solo per mantenere un'implementazione come OpenSSL?
La concorrenza è una buona cosa, così come la ridondanza / diversità.
Sebbene Heartbleed abbia influito su molti sistemi e servizi a causa di quanto sia diffuso OpenSSL, certamente non ha influenzato il 100% dei sistemi. Avere ridondanza nel software in generale è un bene, se si ha un problema con un pezzo di software si può fallire in un altro o mitigare il rischio diffondendo le dipendenze del software tra più fornitori (proprio come faresti con l'hardware).
In secondo luogo, la competizione nel business porta efficienza e qualità. Lo stesso vale per il software. Se arriva una soluzione più facile da usare, più efficiente o comunque migliore, potrebbe superare il software stabilito o forzare il miglioramento del software stabilito.
Questa domanda può essere facilmente estesa a qualsiasi problema che possa essere risolto da una libreria, correlata alla sicurezza o meno. Questa risposta si applica alle librerie che implementano qualsiasi funzionalità standardizzata e non è specifica per SSL.
Non tutte le licenze software sono compatibili tra loro. Quando si desidera utilizzare una libreria con licenza GPL, è necessario concedere in licenza l'intero progetto in GPL, che potrebbe non rientrare nella strategia aziendale. Altre organizzazioni potrebbero rifiutare tutto tranne una licenza specifica per ragioni ideologiche. Ciò porta a soluzioni multiple per lo stesso problema che in pratica differiscono solo per i termini della licenza.
Anche quando uno standard in sé non è brevettato, potrebbe essere un certo metodo per implementare quello standard. In tal caso, devi utilizzare il metodo di implementazione brevettato e pagare la tassa, trasferirti in un paese in cui il brevetto non è applicabile, o creare una nuova implementazione con un metodo diverso che aggira il brevetto.
Spesso accade che due diversi team di sviluppo sviluppino un'implementazione della stessa tecnologia indipendentemente l'una dall'altra. Quando entrambe le soluzioni arrivano sul mercato, nessuno vuole ammettere che la loro soluzione è inferiore, quindi entrambi continueranno a promuovere e mantenere la loro soluzione.
Per assicurarsi che una libreria si interfaccia bene con il tuo programma, preferibilmente dovrebbe essere scritta nello stesso linguaggio di programmazione. Quando hai un programma C, preferiresti una libreria scritta in C. Quando usi Java, ti piacerebbe un'implementazione Java. Quando usi C #, preferisci che sia implementato in .NET. Non è impossibile che entrambe le tecnologie si interfacciano con componenti scritte negli altri, ma richiede sempre un po 'di colla e nastro adesivo per collegarlo all'interfaccia, il che potrebbe compromettere le prestazioni, la leggibilità del codice e rendere più complicata la creazione di toolchain. / p>
Diversi progetti hanno priorità diverse. Alcuni vogliono l'implementazione più rapida possibile. Alcuni hanno bisogno di un ingombro di memoria molto basso. Alcuni vogliono l'implementazione con il miglior track record di sicurezza (che può essere misurato in molti modi diversi). La migliore libreria per un progetto non è necessariamente anche la migliore per un'altra. Avere più opzioni tra cui scegliere può essere utile.
Wouldn't it be cheaper, more productive and faster just to [...]
Ah! Tutta la storia di Mankind.
Esistono diverse implementazioni di SSL per la sola e più potente ragione per cui alcune persone le hanno scritte. Dopotutto, per una nuova implementazione di qualsiasi cosa, per alcuni individui è sufficiente, a un certo punto (forse dopo una troppa pinta), credere che scriverne uno nuovo sarebbe una buona idea. Non esiste una struttura di gestione complessiva che pianifichi e diriga gli sforzi di implementazione di tutti gli sviluppatori sul pianeta. Invece, ci sono migliaia, persino milioni di entità indipendenti che seguono tutti i propri capricci, che non devono essere affatto razionali, per non parlare di un piano generale.
Se guardiamo ai singoli progetti, possiamo vedere alcune differenze tecniche e locali. Sto usando "tecnico" in un senso ampio qui; per esempio. GnuTLS è stato richiesto come concorrente per OpenSSL principalmente a causa di problemi di licenza. Altri hanno sottolineato che una libreria SSL deve, per definizione, integrarsi nel contesto di altre applicazioni, il che implica anche molta variabilità.
Per esempio, una volta, personalmente, ho scritto una nuova implementazione SSL / TLS in C, che è attualmente distribuita in produzione: il cliente aveva bisogno di qualcosa che si adattasse ai suoi dispositivi integrati (in particolare, nel codice di bootstrap per i suoi dispositivi incorporati), e OpenSSL non avrebbe mai funzionato con 20 kB di ROM + 20 kB di RAM, su un sistema operativo barebone che non offre nemmeno una chiamata di malloc() . Il mio codice potrebbe; SSL non è un protocollo di grandi dimensioni, se elimini alcune delle parti opzionali (ad esempio, concentrati su un paio di pacchetti di crittografia, non implementare le estensioni che non ti servono e così via).
C'è un altro motivo, che peraltro non è correlato alla sicurezza: per diventare un protocollo Internet standard, è necessario dimostrare più implementazioni indipendenti interoperabili di quel protocollo. IOW: abbiamo bisogno di più implementazioni di TLS, perché se non avessimo implementazioni multiple di TLS non avremmo TLS!