Perché SSL / TLS non è integrato nei moderni sistemi operativi?

Molti dei protocolli di rete di base che compongono l'infrastruttura di Internet sono integrati nella maggior parte dei principali sistemi operativi. Ad esempio, TCP, UDP e DNS sono tutti integrati in Linux, UNIX e Windows e sono resi disponibili al programmatore tramite API di sistema di basso livello.

Ma quando si tratta di SSL o TLS, si deve rivolgersi a una libreria di terze parti come OpenSSL o Mozilla NSS.

SSL è un protocollo relativamente vecchio ed è fondamentalmente uno standard del settore onnipresente come TCP / IP, quindi perché non è integrato nella maggior parte dei sistemi operativi?

Penso che dipenda principalmente da quello che vedi come "il sistema operativo". Se è il kernel, la mia risposta sarebbe: perché dovrebbe? Potrei sbagliarmi, ma DNS non fa parte di glibc su sistemi Linux, che è una libreria di terze parti?

Se non si tratta dello spazio del kernel o dell'utente, quasi ogni sistema operativo / piattaforma ha uno stack SSL / TLS, alcuni potrebbero averne più di uno.

Può anche essere visto come un vantaggio. Se non ci fosse OpenSSL, dovresti adattarti alle API di Windows, Mac e Linux (e ...). TLS che non fa parte del sistema operativo consente di scrivere applicazioni TLS multipiattaforma. Basta scegliere una libreria TLS che supporti le piattaforme di destinazione.

Per me, il vero problema con TLS è che non puoi semplicemente "accenderlo". Invece, devi gestire una serie di certificati attendibili, elenchi di revoche di certificati, certificati autofirmati e così via. Tutti questi richiedono molta interazione dell'utente.

Purtroppo, la sicurezza non arriva mai gratuitamente. È uno sforzo per i programmatori e un inconveniente per gli utenti.

C'è un problema legale. Alcuni paesi inseriscono la crittografia nello stesso gruppo delle armi. Inserire il codice crittografico nel kernel rende più difficile l'esportazione di qualsiasi codice del kernel.

Ci sono evidenti vantaggi nella creazione di TCP nel sistema operativo. TCP richiede un tempismo di precisione e una risposta rapida ai pacchetti di rete anche quando non sono coinvolti dati dell'applicazione. Se si provasse a implementare TCP nello spazio utente sopra un'API IP generica, sarebbe molto peggio. Non ci sono vantaggi simili all'integrazione di SSL nel kernel.

D'altra parte, ci sono alcuni svantaggi. Ad esempio, SSL richiede la manipolazione di portachiavi ed elenchi di certificati e simili. Farlo tramite un kernel o un'API del sistema operativo sarebbe inelegante. Quindi, anche se fornito con il sistema operativo, sarebbe solo una libreria (proprio come in Windows). Quelle librerie sono già disponibili comunque, quindi alla fine è solo un cambiamento nella confezione.

Ci sono una serie di ragioni, ma forse il più convincente è che la crittografia è molto, molto difficile da ottenere in realtà a destra . Non è saggio implementarlo da soli a meno che non si possano dedicare risorse importanti alla verifica che sia corretto e forte. Molte persone che lavorano con software crittografico non hanno il tempo, l'esperienza o il desiderio di impantanarsi in questo; si fidano delle librerie di terze parti in modo che i loro sviluppatori possano gestire quella parte del lavoro, mentre gli sviluppatori di applicazioni possono tornare a fare ciò che vogliono fare.

Gli sviluppatori del sistema operativo non sono così diversi. A volte c'è un interesse prevalente - ad esempio, il tuo modello di business o i tuoi avvocati richiedono di tenere chiuso il codice - e quindi non hai molta scelta in materia: se non riesci a trovare qualcuno che ti lascerà fare quello che devi fare, quindi devi farlo da solo. Altri hanno già menzionato come Microsoft fa questo. Ma in generale, gli sviluppatori di sistemi operativi che possono utilizzare librerie di terze parti preferiscono farlo in questo modo, per gli stessi motivi degli sviluppatori di applicazioni.

Sono uno sviluppatore di Windows, quindi non posso parlare per altri sistemi operativi, ma su Windows avevano SSL integrato da molto tempo. Lo chiamano SChannel e mentre è supportato, è una delle API più criptiche che uno dovrebbe mai capire.

SSL è un livello sopra un protocollo di livello inferiore. Ad esempio SSL viene eseguito sopra TCP (che è sopra IP).

Dove si ferma il sistema operativo?

È molto facile sostenere che il sistema operativo fornisce servizi di base come la rete fino a un punto in cui un client del sistema operativo "fa cose". E quella roba può essere quello che vuoi.

È abbastanza improbabile che SSL nel kernel porti a un enorme aumento delle prestazioni, quindi perché preoccuparsi?

I kernel del sistema operativo moderno vengono eseguiti su milioni di righe di codice, l'aggiunta di più aggiunge complessità e più tempo di debug. Lasciare cose come roba di protocollo di livello superiore fuori dal sistema operativo semplifica lo sviluppo del sistema operativo e alla fine fa poca differenza per la funzione o le prestazioni di un'applicazione finale. (Potrebbe rendere il lavoro degli sviluppatori per l'applicazione finale un po 'più doloroso.)

C'è un po 'di supporto del kernel per Crypto e SSL. Ciò ha senso perché il kernel può interfacciarsi in modo più efficiente con l'hardware ed è anche conveniente proteggere le credenziali da qualsiasi applicazione. Buoni esempi sono kssl, un proxy SSL inverso a livello di kernel in Solaris o le varie librerie di crittografia nel kernel (utilizzate ad esempio per le VPN). Un tipico motore crittografico con accelerazione hardware ha anche un modulo kernel (ed è accessibile tramite interfacce crittografiche PKCS # 11 o specifiche del sistema operativo).

Alcuni motivi per cui non lo vedi più spesso è che alcuni protocolli applicativi non sono correttamente stratificati (pensa a STARTLS) o richiedono decisioni applicative durante la stretta di mano (pensa certificato client e controllo CRL) o sono semplicemente in una regolare evoluzione.