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

Penso che dipenda principalmente da ciò che vedi come "il sistema operativo". Se è il kernel, la mia risposta sarebbe: perché dovrebbe? Potrei sbagliarmi, ma il DNS non fa parte degli glibc sui sistemi Linux, che è una libreria thrid-party?

Se non si tratta di kernel o spazio utente, quasi ogni OS / piattaforma ha uno stack SSL / TLS, alcuni potrebbero avere 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 non essendo parte del sistema operativo consente di scrivere applicazioni TLS multipiattaforma. Scegli una libreria TLS, che supporti le tue piattaforme di destinazione.

Per me, il vero problema con TLS è che non puoi semplicemente "accenderlo". Invece, devi gestire una serie di certificati affidabili, elenchi di revoche di certificati, certificati autofirmati e così via. Tutto ciò richiede molte interazioni con l'utente.

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

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

Ci sono evidenti vantaggi nella creazione di TCP nel sistema operativo. Il protocollo TCP richiede tempi precisi e risposta rapida ai pacchetti di rete anche quando non sono coinvolti dati applicativi. Se si tentasse di implementare TCP nello spazio utente su 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 key ring e liste di certificati e simili. Fare ciò attraverso un kernel o un'API del sistema operativo sarebbe inelegante. Quindi, anche se viene 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 motivi, ma forse il più convincente è che la crittografia è molto, molto difficile da ottenere effettivamente giusto . Non è saggio implementarlo da soli se non si possono dedicare risorse importanti per verificare che sia corretto e strong. La maggior parte delle persone che lavorano con software crittografico non hanno il tempo, la competenza 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.

Gli sviluppatori di sistemi operativi non sono così diversi. A volte c'è un interesse prioritario: per esempio, il tuo modello di business o gli avvocati ti richiedono di mantenere il codice chiuso e quindi non hai molta scelta in materia: se non riesci a trovare qualcuno che ti lascerà fare quello che devi, poi devi tirare il tuo. 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 che fanno gli sviluppatori di applicazioni.

Sono uno sviluppatore di finestre, quindi non posso parlare per altri sistemi operativi, ma su Windows hanno integrato SSL per un tempo molto lungo. Lo chiamano SChannel e mentre è supportato, è uno dei le API più criptiche che uno dovrebbe mai capire.

SSL è uno strato sopra l'alto di un protocollo di livello inferiore. Ad esempio, SSL viene eseguito nella parte superiore del protocollo TCP (che è al di sopra dell'IP).

Dove si ferma il sistema operativo?

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

È piuttosto improbabile che SSL nel kernel possa portare a un enorme guadagno di prestazioni, quindi perché preoccuparsi?

I moderni kernel del sistema operativo corrono a milioni di linee di codice, aggiungendo di più si aggiungono solo complessità e tempi di debug. Lasciare cose come il protocollo di livello superiore fuori dal sistema operativo rende più semplice 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 supporto per il kernel per Crypto e SSL. Questo ha senso perché il kernel può interfacciarsi in modo più efficiente con l'hardware ed è anche conveniente per proteggere le credenziali da qualsiasi applicazione. Buoni esempi sono kssl, un proxy reverse-SSL a livello kernel in Solaris o le varie librerie crittografiche nel kernel (utilizzate ad esempio per VPN). Un tipico motore di crittografia hardware accelerato ha anche un modulo del kernel (ed è accessibile tramite PKCS # 11 o interfacce crittografiche specifiche del sistema operativo).

Alcuni motivi per cui non lo si vede più spesso è che alcuni protocolli di applicazione non sono stratificati correttamente (si pensi a STARTLS) o richiedono decisioni applicative durante l'handshake (si pensi al certificato client e al controllo CRL) o sono semplicemente in evoluzione regolare.