webdev-1996
Shell-accounts, SSLeay en de vroege webrealiteit
Deze pagina beschrijft de technische oorsprong van sslxy. Niet als legende, niet als merkopbouw, maar als restant van een concrete omgeving: UNIX-shell-account, vroege cryptografie-experimenten, CGI, logbestanden en een web dat met heel weinig moest uitkomen.
De naam kwam niet voort uit een creatief concept, maar uit infrastructuur. Juist daarom is hij gebleven. Hij was kort, functioneel, technisch plausibel en jarenlang eenvoudigweg de naam waaronder dingen draaiden.
System Diagnostic
De naam: geen pseudoniem, maar een technisch restant
Achter sslxy schuilt geen grote uitvinding. De naam ontstond in 1996 uit een technische omgeving waarin namen niet vooral goed moesten klinken, maar moesten werken. Kort. Makkelijk invoerbaar. Zonder problemen bruikbaar in bestandsnamen, logbestanden en accounts.
De oorsprong lag in een test- en werkomgeving rond een shell-account en eerste experimenten met SSL-software. Uit een technische context zoals ssl-server-xy ontstond een verkorte vorm die praktisch was als gebruikersnaam en aanduiding. Precies daaruit bleef sslxy over.
Dat was geen merkbeslissing. Het was eerder wat in technische omgevingen vaak gebeurt: een naam wordt één keer nodig, werkt, duikt op in logs, directories en mailcontexten en blijft dan, omdat er geen goede reden is om hem weer los te laten.
> Host-/werknaam met SSL-verwijzing
> verkorte aanduiding voor login, directories, logs
> sslxy blijft als handle bestaan
Beslissend is niet dat de naam bijzonder origineel zou zijn geweest, maar dat hij technisch bruikbaar was. Dat past tot op vandaag beter bij hem dan elke latere, achteraf gegeven betekenis.
Shell-account en serverrealiteit
Webontwikkeling in 1996 had weinig te maken met het huidige gereedschapspakket. Er was geen comfortabele browser-inspector, geen build-ketens, geen geautomatiseerde deployments en geen hosting-interface die je de technische details uit handen nam. Wie iets wilde wijzigen, ging naar de server of naar een shell-account en werkte daar direct.
Typisch was een inbelverbinding via modem of ISDN, daarna Telnet of een vergelijkbare terminalverbinding, plus FTP voor bestandsoverdracht. Bewerken gebeurde met vi, pico of lokaal in een eenvoudige editor met daarna uploaden. Zelfs regeleinden konden problemen veroorzaken. Bestandsrechten moesten kloppen. Paden moesten kloppen. CGI-scripts moesten uitvoerbaar zijn.
Als een formulier niet werkte, verscheen er geen vriendelijke diagnose in de browser. In plaats daarvan kwam er vaak alleen een 500 Internal Server Error. Het eigenlijke werk begon dan pas: logbestand openen, interpreter-pad controleren, bestandsrechten nakijken, foutregel in het Perl-script zoeken, opnieuw uploaden, opnieuw testen.
- Upload en onderhoud: via FTP of direct in de home-directory van het account.
- Foutanalyse: primair via ruwe HTTP- en CGI-logbestanden.
- Interactiviteit: vrijwel altijd server-side, niet in de browser.
- Gereedschapshouding: klein gereedschapsset, maar hoge kennis van de basis.
Deze omgeving vormde een soort nuchterheid die later bleef. Als elke fout onmiddellijk zichtbaar is en elke correctie handmatig gebeurt, leer je vroeg om onnodige complexiteit te vermijden.
SSLeay en vroege veiligheid
Wie vandaag aan HTTPS denkt, denkt aan geautomatiseerde certificaten, kant-en-klare beheerinterfaces en achtergrondprocessen die vernieuwingen stil afhandelen. Halverwege de jaren 1990 was dat anders. Cryptografie was veel directer, stroever en minder geabstraheerd.
SSLeay was een vroege cryptografie- en SSL/TLS-bibliotheek, uit wiens lijn later OpenSSL voortkwam. In de praktijk betekende dat: configuratiebestanden, commandoregelgereedschap, handmatig gegenereerde sleutels en certificaatverzoeken, plus het besef dat versleuteling niets magisch is, maar een concreet gebouwd technisch proces met veel plekken waar je fouten kon maken.
Juist die vroege nabijheid tot de techniek was belangrijk. Veiligheid was niet zomaar een schakelaar in een beheerinterface, maar iets wat je moest kunnen volgen. Dat heeft een andere verhouding tot infrastructuur gevormd dan moderne gereedschappen, die veel correct verbergen, maar ook veel succesvol loskoppelen.
> sleutels genereren
> certificaatverzoek maken
> serverconfiguratie aanpassen
> testen, lezen, begrijpen in plaats van klikken
Uit deze fase stamt ook een deel van de latere houding ten opzichte van webveiligheid: liever begrijpelijke, kleine en controleerbare configuraties dan moeilijk doorgrondbare complexiteit.
HTML 2.0 en echte browserpraktijk
Historisch zuiver moet men twee dingen scheiden: de formele specificatie en de praktijk in de browsers. De formele basis van het web was in 1996 nog sterk door HTML 2.0 bepaald. Tegelijk gebruikten veel browsers al uitbreidingen en functies die niet tot de zuivere HTML-2.0-specificatie behoorden, maar later gangbaar of gestandaardiseerd werden.
Dat is belangrijk, omdat achteraf veel al snel tot één enkel verhaal wordt samengevoegd. Zuiver formeel was HTML 2.0 soberder. In de praktijk werkten ontwikkelaars in 1996 echter vaak al met extra BODY-attributen, tabellen en andere browsergerichte uitbreidingen, omdat precies die dingen in het dagelijks werk hielpen.
- HTML 2.0 als basis: koppen, alinea's, lijsten, links, afbeeldingen, eenvoudige formulieren.
- Browserpraktijk 1996: kleuraanduidingen in
<body>, tabellen, extra presentatiemiddelen. - Belangrijk onderscheid: wijdverbreid betekent niet automatisch zuiver onderdeel van dezelfde specificatie.
In het dagelijkse werk speelde dat onderscheid voor veel ontwikkelaars aanvankelijk geen grote rol. Doorslaggevend was wat in Netscape of Internet Explorer daadwerkelijk werkte. Precies daaruit ontstond de webpraktijk van toen: minder normzuiver, maar vaak pragmatisch.
> HTML 2.0 = structurele basis
[Praktisch niveau]
> browseruitbreidingen = waarmee er echt gebouwd werd
> 1996 is technisch een overgangsfase, geen zuivere afzonderlijke toestand