Ons het 'n webtoepassing (Apache/PHP) wat tans gebruikernaam-/wagwoordverifikasie gebruik en tans vanaf enige plek toeganklik is. Dit het SSL aan die bedienerkant geaktiveer.

Ons kliëntprogram is 'n weergawe van FireFox wat ons gewysig en herbrand het. Hierdie gewysigde firefox-kliënt is slegs bedoel om aan ons webtoepassingsbediener te koppel. Gebruikers moet hierdie kliëntprogram gebruik om aan die webdiens te koppel.

Benewens gebruikers-verifikasie, wil ons graag toegang op die bedienervlak blokkeer vir enigiemand wat nie ons kliëntprogram* gebruik nie. So as 'n gebruiker 'n URI intik met 'n gewone blaaier, sal hulle heeltemal geweier word.

Om dit te bereik, moet die kliëntprogram homself aan die bediener identifiseer sodat die bediener weet dat ons kliëntprogram gebruik word en nie 'n webblaaier of bot nie.

*Die eintlike doel is om seker te maak dat hulle gemagtigde werknemers van ons maatskappy is voordat hulle kan probeer om aan te meld, om hierdie "bewys van indiensneming" in die kliëntprogram in te sluit blyk net die maklikste manier te wees om dit te doen, aangesien die toepassing slegs gegee aan mense wat 'n behoefte het om dit te gebruik..

Tot dusver het ek 'n paar idees gehad oor hoe om dit te bereik.

1.) Sluit 'n tolk in die kliënttoepassing in wat gestuur word wanneer die kliënt 'n aanmelding doen (aanmelding word deur 'n chrome/XUL-koppelvlak hanteer). Dit sal nie op die bedienervlak blokkeer nie, net op die toepassingsvlak. Die sleutel kan so maklik soos 'n wagwoord gesteel word, maar nie so maklik deur brute geweld geraai word nie, aangesien dit enige lengte of kompleksiteit kan wees.

1a.) Voeg 'n spesiale tolken parameter by die kliënt blaaier kop op alle versoeke. Dit is meer soos sekuriteit-deur-onduidelikheid, maar kan beslis 'n aanvaller vertraag wat probeer om wagwoorde brutaal te dwing as aanmelding altyd misluk (selfs met die regte wagwoord) wanneer die towerstring in die versoek ontbreek.

2.) Sluit 'n kliënt SSL-sertifikaat in die kliëntprogram in. Dit lyk asof dit 'n goeie oplossing kan wees, maar goeie dokumentasie op cleint-kant SSL bestaan ​​amper nie. Ons wil NIE 'n sertifikaat vir elke gebruiker teken nie, en ons wil ook nie hê dat die gebruiker 'n sertifikaat moet skep of hoegenaamd gepla word met sekuriteitsdialoog nie. Die private sleutel sal in die blaaier ingebed moet word, en sal een sleutel wees wat onder alle kliëntprogramme gedeel word, en per-geïnstalleerd in ons pasgemaakte blaaier versprei word.

3.) Gaan die gebruikeragent-string na. Ek dink Apache kan op grond hiervan beperk. Maar dit lyk op sy beste na 'n swak maatstaf. Ek sal dit waarskynlik bykomend tot ander maatreëls doen.

Ek hoop vir 'n beter idee oor hoe om dit te doen?

answer

Om 'n kliënt SSL-sertifikaat by die gewysigde blaaier in te sluit, sal die maklikste en waarskynlik veiliger wees.

As jy dieselfde sleutel vir almal gebruik, verloor jy baie van die voordele van kliëntsertifikate, maar dit is beter as om gebruikersagent na te gaan. En ek neem aan jy sal steeds 'n gebruikersnaam en wagwoord benodig om aan te meld.

Het u al aan VPN gedink? Dit klink soos presies wat jy regtig wil hê.