---

Jeg har erhvervet mig en IBM ThinkPak T43P, som er en fantastisk
maskine, hvis ikke lige det var, fordi dens sikkerhed forhindrer:

- at jeg kan logge ind på SKAT.dk med digital signatur. Jeg får
følgende besked: "Unable to create zip cache dir C:\Documents and
Settings\mitbrugernavn\.oces\opensign\plugins"

- at jeg ikke kan køre remote backup (Online Backup Manager)

Jeg har haft TDC til at checke alt, og SKAT har haft en teknikker på,
så nu er jeg ved at give op.

Er der nogen, der kan hjælpe?

Mvh. John

---

On Sun, 2007-05-27 at 01:50 -0700, johndalgaard@hotmail.com wrote:
> Jeg har erhvervet mig en IBM ThinkPak T43P, som er en fantastisk
> maskine, hvis ikke lige det var, fordi dens sikkerhed forhindrer:

Hvordan er du sikker på det er dens sikkerhed, der er problemmet?

> - at jeg kan logge ind på SKAT.dk med digital signatur. Jeg får
> følgende besked: "Unable to create zip cache dir C:\Documents and
> Settings\mitbrugernavn\.oces\opensign\plugins"

Hvilke rettigheder er der til dette katalog, og har du dem?

> - at jeg ikke kan køre remote backup (Online Backup Manager)

Hvad er remote backup, og hvilken fejlbesked får du?

---

<- at jeg kan logge ind på SKAT.dk med digital signatur. Jeg får
<følgende besked: "Unable to create zip cache dir C:\Documents and
<Settings\mitbrugernavn\.oces\opensign\plugins"

Har haft samme problem, her var det McAfee som ikke tillod den slags.

<- at jeg ikke kan køre remote backup (Online Backup Manager)

Her er det ikke nemt at gætte hvad kan være galt med den meget korte
beskrivelse.
Jeg tror ikke man skal skyde skylden på computeren med den slags fejl, det
er somregel altid softwaren der driller.

Mvh Anders

---

johndalgaard@hotmail.com wrote:
> Jeg har erhvervet mig en IBM ThinkPak T43P, som er en fantastisk
> maskine, hvis ikke lige det var, fordi dens sikkerhed forhindrer:
>
> - at jeg kan logge ind på SKAT.dk med digital signatur. Jeg får
> følgende besked: "Unable to create zip cache dir C:\Documents and
> Settings\mitbrugernavn\.oces\opensign\plugins"
>

Denne fejl skyldes at SKAT bruger et uigennemtænkt system til at
validere login med digital signatur. Hele opensign plugin bygger
på et misforstået sikkerhedskoncept, og det er skideærgeligt at
det lykkedes nogle fjolser at spilde alle de kræfter der skulle have
været brugt på at lave Linux/BSD/Open Source support for TDC digital
signatur i stedet for på dette makværk.

Konkret gætter jeg på at du kører Internet Explorer under Vista. Lige
præcis denne kombination af operativsystem og browser indeholder en
effektiv beskyttelse mod browserplugins der prøver at få fat på ting
uden for browseren, herunder den omtalte opensign plugin (som er noget
af den slags der SKAL standses af et godt sikkerhedssystem).

Til login på skat vil jeg anbefale at du går tilbage til at bruge
"tast-selv-kodeord", det er mere sikkert end Skats nuværende løsning.


> - at jeg ikke kan køre remote backup (Online Backup Manager)
>

Hvilket konkret produkt drejer det sig om? Er dette produkt
Vista-kompatibelt (hvis du altså kører Vista).


> Jeg har haft TDC til at checke alt, og SKAT har haft en teknikker på,
> så nu er jeg ved at give op.
>

Tjah, i betragtning af de forvirrede pressemeldinger TDC og Skat
udsendte tidligere på året om at det var Vistas skyld at deres løsning
var en gang klamp undrer dette mig ikke spor...

> Er der nogen, der kan hjælpe?
>
> Mvh. John
>


--
Jakob Bøhm, M.Sc.Eng. * jb@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right

---

Jakob Bøhm <jb@danware.dk> wrote:

> johndalgaard@hotmail.com wrote:
>
> > Jeg har erhvervet mig en IBM ThinkPak T43P, som er en fantastisk
> > maskine, hvis ikke lige det var, fordi dens sikkerhed forhindrer:
> >
> > - at jeg kan logge ind på SKAT.dk med digital signatur. Jeg får
> > følgende besked: "Unable to create zip cache dir C:\Documents and
> > Settings\mitbrugernavn\.oces\opensign\plugins"
> >
>
> Denne fejl skyldes at SKAT bruger et uigennemtænkt system til at
> validere login med digital signatur. Hele opensign plugin bygger
> på et misforstået sikkerhedskoncept, og det er skideærgeligt at
> det lykkedes nogle fjolser at spilde alle de kræfter der skulle have
> været brugt på at lave Linux/BSD/Open Source support for TDC digital
> signatur i stedet for på dette makværk.
>
> Konkret gætter jeg på at du kører Internet Explorer under Vista. Lige
> præcis denne kombination af operativsystem og browser indeholder en
> effektiv beskyttelse mod browserplugins der prøver at få fat på ting
> uden for browseren, herunder den omtalte opensign plugin (som er noget
> af den slags der SKAL standses af et godt sikkerhedssystem).

F.eks

"Allow Microsoft Windows registry access ...... yes" ?

Men nu bruger Skat svjks OpenLogon og ikke OpenSign.

http://www.openoces.org/demo/index.html

Det skat bruger ligner i hvert fald mere OpenLogon applet.

På en Mac (med OS X) kan man vælge at bruge sit OCES fra selve
pkcs12-filen, f.eks den man har som backup - og med password
beskyttelse. Man skal i så fald vælge kun at ha' hak i kassen ud for
Pkcs12 - og fjerne alle de andre.

Er det ikke osse en mulighed i Vista?

I øvrigt tillykke til Microsoft, for et mere sikkert OS.

---

hlexa@hotmail.com (Axel Hammerschmidt) wrote in
news:1hywcjb.157fnd9z8l6iaN%hlexa@hotmail.com:

> Jakob Bøhm <jb@danware.dk> wrote:
>
>> johndalgaard@hotmail.com wrote:
>>
>> > Jeg har erhvervet mig en IBM ThinkPak T43P, som er en fantastisk
>> > maskine, hvis ikke lige det var, fordi dens sikkerhed forhindrer:
>> >
>> > - at jeg kan logge ind på SKAT.dk med digital signatur. Jeg får
>> > følgende besked: "Unable to create zip cache dir C:\Documents and
>> > Settings\mitbrugernavn\.oces\opensign\plugins"
>> >
>>
>> Denne fejl skyldes at SKAT bruger et uigennemtænkt system til at
>> validere login med digital signatur. Hele opensign plugin bygger
>> på et misforstået sikkerhedskoncept, og det er skideærgeligt at
>> det lykkedes nogle fjolser at spilde alle de kræfter der skulle have
>> været brugt på at lave Linux/BSD/Open Source support for TDC digital
>> signatur i stedet for på dette makværk.
>>
>> Konkret gætter jeg på at du kører Internet Explorer under Vista. Lige
>> præcis denne kombination af operativsystem og browser indeholder en
>> effektiv beskyttelse mod browserplugins der prøver at få fat på ting
>> uden for browseren, herunder den omtalte opensign plugin (som er noget
>> af den slags der SKAL standses af et godt sikkerhedssystem).
>
> F.eks
>
> "Allow Microsoft Windows registry access ...... yes" ?
>
> Men nu bruger Skat svjks OpenLogon og ikke OpenSign.
>
> http://www.openoces.org/demo/index.html
>
> Det skat bruger ligner i hvert fald mere OpenLogon applet.
>
> På en Mac (med OS X) kan man vælge at bruge sit OCES fra selve
> pkcs12-filen, f.eks den man har som backup - og med password
> beskyttelse. Man skal i så fald vælge kun at ha' hak i kassen ud for
> Pkcs12 - og fjerne alle de andre.
>
> Er det ikke osse en mulighed i Vista?

Det er da en mulighed med IE6 og W2K.

Først eksporterer man sit certifikat - med den private nøgle - til en
password beskyttet fil og sørger for at filen ligger et sted hvor man har
skrive og læse rettigheder (ellers kan man jo ikke eksporterer
certifikatet). Det bliver til en pfx-fil (så vidt jeg husker).

Når man så vil log on til Skat vælger man Browse og udpeger filen og
trykker på OK knappen. Så skulle man komme ind på sit private "område"
hos Skat.

Det virkede som sagt med IE6 og W2K. Der skulle ikke være noget i vejen
for at det virker med Vista.


--
The American Psychological Association has found the sexual
objectification of girls leads to academic failure, depression, eating
disorders and poor self-image.

---

Axel Hammerschmidt wrote:
> hlexa@hotmail.com (Axel Hammerschmidt) wrote in
> news:1hywcjb.157fnd9z8l6iaN%hlexa@hotmail.com:
>
>> Jakob Bøhm <jb@danware.dk> wrote:
>>
>>> johndalgaard@hotmail.com wrote:
>>>
>>>> Jeg har erhvervet mig en IBM ThinkPak T43P, som er en fantastisk
>>>> maskine, hvis ikke lige det var, fordi dens sikkerhed forhindrer:
>>>>
>>>> - at jeg kan logge ind på SKAT.dk med digital signatur. Jeg får
>>>> følgende besked: "Unable to create zip cache dir C:\Documents and
>>>> Settings\mitbrugernavn\.oces\opensign\plugins"
>>>>
>>> Denne fejl skyldes at SKAT bruger et uigennemtænkt system til at
>>> validere login med digital signatur. Hele opensign plugin bygger
>>> på et misforstået sikkerhedskoncept, og det er skideærgeligt at
>>> det lykkedes nogle fjolser at spilde alle de kræfter der skulle have
>>> været brugt på at lave Linux/BSD/Open Source support for TDC digital
>>> signatur i stedet for på dette makværk.
>>>
>>> Konkret gætter jeg på at du kører Internet Explorer under Vista. Lige
>>> præcis denne kombination af operativsystem og browser indeholder en
>>> effektiv beskyttelse mod browserplugins der prøver at få fat på ting
>>> uden for browseren, herunder den omtalte opensign plugin (som er noget
>>> af den slags der SKAL standses af et godt sikkerhedssystem).
>> F.eks
>>
>> "Allow Microsoft Windows registry access ...... yes" ?
>>
>> Men nu bruger Skat svjks OpenLogon og ikke OpenSign.
>>
>> http://www.openoces.org/demo/index.html
>>
>> Det skat bruger ligner i hvert fald mere OpenLogon applet.
>>
>> På en Mac (med OS X) kan man vælge at bruge sit OCES fra selve
>> pkcs12-filen, f.eks den man har som backup - og med password
>> beskyttelse. Man skal i så fald vælge kun at ha' hak i kassen ud for
>> Pkcs12 - og fjerne alle de andre.
>>
>> Er det ikke osse en mulighed i Vista?
>
> Det er da en mulighed med IE6 og W2K.
>
> Først eksporterer man sit certifikat - med den private nøgle - til en
> password beskyttet fil og sørger for at filen ligger et sted hvor man har
> skrive og læse rettigheder (ellers kan man jo ikke eksporterer
> certifikatet). Det bliver til en pfx-fil (så vidt jeg husker).
>
> Når man så vil log on til Skat vælger man Browse og udpeger filen og
> trykker på OK knappen. Så skulle man komme ind på sit private "område"
> hos Skat.
>
> Det virkede som sagt med IE6 og W2K. Der skulle ikke være noget i vejen
> for at det virker med Vista.
>
>

(Jeg forudsætter fortsat at OP faktisk kører Vista, dette er aldrig
blevet oplyst, kun hardware-opsætningen).

På Vista er der en sikkerhedsfeature hvor hele Internet Explorer køres i
en lukket sandkasse hvor både IE og de plugins der kaldes fra IE kun har
adgang til nogle få Internet-relevante kataloger og registry keys.
Herved forhindrer man hjemmesider i at gå ind og stjæle eller manipulere
værdifulde filer som f.eks. den private nøgle til digital signatur. Man
forhindrer også at plugins prøver at lægge filer på steder hvor de ikke
har noget at gøre, som f.eks. direkte i %USERPROFILE%.

OpenSign/OpenLogon begår den indledende fejl at forsøge at downloade
sine indre komponenter til et sted udenfor sandkassen, og når derfor
aldrig at blive fuldstændigt downloadet. Dermed kommer opensign slet
ikke i gang på Vista uanset hvordan man fjerner beskyttelsen af sin
digitale signatur.

De fundamentale misforståelser i OpenSign/OpenLogon er dog to andre ting:

1. "Det er ikke en sikkerhedsrisiko at bruge en plugin som signerer
arbitrær tekst med brugerens digitale signatur uden at brugeren har en
reel mulighed for at se og tage stilling til hvad han/hun skriver under
på" .
Dette er oplagt forkert. Også selvom den hjemmeside der bruger den
pågældende plugin i dag tilfældigvis bare signerer en "tom" XML-fil med
et løbenummer for logonforsøget. For en anden hjemmeside kunne jo kalde
den pågældende plugin med en XML-fil hvor der stod "Fortæl
tinglysningskontoret at jeg lige har solgt mit hus for 1 kr. til hr. tyv"

2. "Det er en fejl hvis et sikkerhedssystem forhindrer plugins i at gøre
ting som i punkt 1" .

Et godt sikkerhedssystem har al mulig grund til at stoppe den slags plugins.



--
Jakob Bøhm, M.Sc.Eng. * jb@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right

---

Jakob Bøhm <jb@danware.dk> wrote:

> Axel Hammerschmidt wrote:

> > hlexa@hotmail.com (Axel Hammerschmidt) wrote in
> > news:1hywcjb.157fnd9z8l6iaN%hlexa@hotmail.com:

<snip>

> >> Er det ikke osse en mulighed i Vista?
> >
> > Det er da en mulighed med IE6 og W2K.
> >
> > Først eksporterer man sit certifikat - med den private nøgle - til en
> > password beskyttet fil og sørger for at filen ligger et sted hvor man har
> > skrive og læse rettigheder (ellers kan man jo ikke eksporterer
> > certifikatet). Det bliver til en pfx-fil (så vidt jeg husker).
> >
> > Når man så vil log on til Skat vælger man Browse og udpeger filen og
> > trykker på OK knappen. Så skulle man komme ind på sit private "område"
> > hos Skat.
> >
> > Det virkede som sagt med IE6 og W2K. Der skulle ikke være noget i vejen
> > for at det virker med Vista.
>
> (Jeg forudsætter fortsat at OP faktisk kører Vista, dette er aldrig
> blevet oplyst, kun hardware-opsætningen).
>
> På Vista er der en sikkerhedsfeature hvor hele Internet Explorer køres i
> en lukket sandkasse hvor både IE og de plugins der kaldes fra IE kun har
> adgang til nogle få Internet-relevante kataloger og registry keys.
> Herved forhindrer man hjemmesider i at gå ind og stjæle eller manipulere
> værdifulde filer som f.eks. den private nøgle til digital signatur. Man
> forhindrer også at plugins prøver at lægge filer på steder hvor de ikke
> har noget at gøre, som f.eks. direkte i %USERPROFILE%.
>
> OpenSign/OpenLogon begår den indledende fejl at forsøge at downloade
> sine indre komponenter til et sted udenfor sandkassen, og når derfor
> aldrig at blive fuldstændigt downloadet. Dermed kommer opensign slet
> ikke i gang på Vista uanset hvordan man fjerner beskyttelsen af sin
> digitale signatur.

Når det drejer sig om *OpenLogin* (eller www.skat.dk) så downloader
sitet nogle filer (jeg mener det er Java applets mm) i brugerens
"hjemmemappe" - i Documents and Settings\brugernavn. Det er sådan set OK
og der skulle ikke være noget til hinder for det.

Og når det lige drejer sig om OCES og W2K - med NTFS og en begrænset
bruger konto, så kan man åbenbart installerer sit certifikat via
Internet kontrolpanelet (som man osse kan få adgang til via IE6) som
begrænset bruger. Man behøver ikke skifte til Administrator kontoen.

Så jeg vil foreslå OP at eksportere (vælg pkcs12-fil) sit certifikat til
en password beskyttet fil i sit "hjemmemappe" - enten fra sin begrænset
bruger konto eller Administrator kontoen - afhængig af om certifikatet i
sin tid blev installeret fra den ene konto eller fra den anden konto. Så
skulle der være læse adgang til certifikatet.

Og så bruge metoden ovenfor til at få adgang til Skat.

---

hlexa@hotmail.com (Axel Hammerschmidt) writes:

>Når det drejer sig om *OpenLogin* (eller www.skat.dk) så downloader
>sitet nogle filer (jeg mener det er Java applets mm) i brugerens
>"hjemmemappe" - i Documents and Settings\brugernavn. Det er sådan set OK
>og der skulle ikke være noget til hinder for det.

Protected Mode i Vista er i høj grad til hinder for det.

Mvh.
   Klaus.

---

Axel Hammerschmidt wrote:
> Jakob Bøhm <jb@danware.dk> wrote:
>
>> Axel Hammerschmidt wrote:
>
>>> hlexa@hotmail.com (Axel Hammerschmidt) wrote in
>>> news:1hywcjb.157fnd9z8l6iaN%hlexa@hotmail.com:
>
> <snip>
>
>>>> Er det ikke osse en mulighed i Vista?
>>> Det er da en mulighed med IE6 og W2K.
>>>
>>> Først eksporterer man sit certifikat - med den private nøgle - til en
>>> password beskyttet fil og sørger for at filen ligger et sted hvor man har
>>> skrive og læse rettigheder (ellers kan man jo ikke eksporterer
>>> certifikatet). Det bliver til en pfx-fil (så vidt jeg husker).
>>>
>>> Når man så vil log on til Skat vælger man Browse og udpeger filen og
>>> trykker på OK knappen. Så skulle man komme ind på sit private "område"
>>> hos Skat.
>>>
>>> Det virkede som sagt med IE6 og W2K. Der skulle ikke være noget i vejen
>>> for at det virker med Vista.
>> (Jeg forudsætter fortsat at OP faktisk kører Vista, dette er aldrig
>> blevet oplyst, kun hardware-opsætningen).
>>
>> På Vista er der en sikkerhedsfeature hvor hele Internet Explorer køres i
>> en lukket sandkasse hvor både IE og de plugins der kaldes fra IE kun har
>> adgang til nogle få Internet-relevante kataloger og registry keys.
>> Herved forhindrer man hjemmesider i at gå ind og stjæle eller manipulere
>> værdifulde filer som f.eks. den private nøgle til digital signatur. Man
>> forhindrer også at plugins prøver at lægge filer på steder hvor de ikke
>> har noget at gøre, som f.eks. direkte i %USERPROFILE%.
>>
>> OpenSign/OpenLogon begår den indledende fejl at forsøge at downloade
>> sine indre komponenter til et sted udenfor sandkassen, og når derfor
>> aldrig at blive fuldstændigt downloadet. Dermed kommer opensign slet
>> ikke i gang på Vista uanset hvordan man fjerner beskyttelsen af sin
>> digitale signatur.
>
> Når det drejer sig om *OpenLogin* (eller www.skat.dk) så downloader
> sitet nogle filer (jeg mener det er Java applets mm) i brugerens
> "hjemmemappe" - i Documents and Settings\brugernavn. Det er sådan set OK
> og der skulle ikke være noget til hinder for det.
>

OP Skrev i første post

> - at jeg kan logge ind på SKAT.dk med digital signatur. Jeg får
> følgende besked: "Unable to create zip cache dir C:\Documents and
> Settings\mitbrugernavn\.oces\opensign\plugins"

Altså at opensign/openlogin/skat IKKE kan få adgang til at skrive i
brugerprofilen. Dette stemmer overens med den sikkerhedsfeature i Vista
som begrænser hele Internet Explorer, inklusive alle plugins til at
skrive i nogle få kataloger som normalt benyttes af plugins

Alle dine EKSTREMT DÅRLIGE RÅD om at fjerne beskyttelsen af den private
nøgle ved at kopiere den rundt til alle mulige og umulige usikre
gemmesteder er altså totalt nyttesløse så længe opensign ikke engang kan
downloade sine klassefiler til sit selvopfundne katalog.



--
Jakob Bøhm, M.Sc.Eng. * jb@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right

---

Jakob Bøhm <jb@danware.dk> wrote:

> Axel Hammerschmidt wrote:
>
> > Jakob Bøhm <jb@danware.dk> wrote:

<snip>

> > Når det drejer sig om *OpenLogin* (eller www.skat.dk) så downloader
> > sitet nogle filer (jeg mener det er Java applets mm) i brugerens
> > "hjemmemappe" - i Documents and Settings\brugernavn. Det er sådan set OK
> > og der skulle ikke være noget til hinder for det.
> >
>
> OP Skrev i første post
>
> > - at jeg kan logge ind på SKAT.dk med digital signatur. Jeg får
> > følgende besked: "Unable to create zip cache dir C:\Documents and
> > Settings\mitbrugernavn\.oces\opensign\plugins"
>
> Altså at opensign/openlogin/skat IKKE kan få adgang til at skrive i
> brugerprofilen. Dette stemmer overens med den sikkerhedsfeature i Vista
> som begrænser hele Internet Explorer, inklusive alle plugins til at
> skrive i nogle få kataloger som normalt benyttes af plugins

Hmm! Hvilke få kataloger? Og får brugeren da heller ikke muligheden
gennem UAP til at give tilladelse? Det lyder mærkeligt, at det skulle
være udelukket.

> Alle dine EKSTREMT DÅRLIGE RÅD om at fjerne beskyttelsen af den private
> nøgle ved at kopiere den rundt til alle mulige og umulige usikre
> gemmesteder er altså totalt nyttesløse så længe opensign ikke engang kan
> downloade sine klassefiler til sit selvopfundne katalog.

Lad være med at være hysterisk. Adgang til filen er password beskyttet.

---

hlexa@hotmail.com (Axel Hammerschmidt) writes:

>> Altså at opensign/openlogin/skat IKKE kan få adgang til at skrive i
>> brugerprofilen. Dette stemmer overens med den sikkerhedsfeature i Vista
>> som begrænser hele Internet Explorer, inklusive alle plugins til at
>> skrive i nogle få kataloger som normalt benyttes af plugins

>Hmm! Hvilke få kataloger?

Dem der er tilgængelige i "Low rights mode".

>Og får brugeren da heller ikke muligheden gennem UAP til at give
>tilladelse?

Du mener UAC? Nej. De to ting har ikke noget med hinanden at gøre.
I Protected Mode kører IE netop *altid* i Low mode. Ellers ville
det jo ikke være beskyttet.

I praksis kan man naturligvis løse det ved at gøre skat.dk til et
"Trusted" site. Så vil rettighederne svare til brugerens normale
rettigheder (altså, Protected Mode er slået fra).

>Det lyder mærkeligt, at det skulle være udelukket.

Hvad er ideen med "Protected Mode", hvis den ikke er "protected"?

Mvh.
   Klaus.

---

Klaus Ellegaard <klausellegaard@msn.com> wrote:

> hlexa@hotmail.com (Axel Hammerschmidt) writes:
>
> >> Altså at opensign/openlogin/skat IKKE kan få adgang til at skrive i
> >> brugerprofilen. Dette stemmer overens med den sikkerhedsfeature i Vista
> >> som begrænser hele Internet Explorer, inklusive alle plugins til at
> >> skrive i nogle få kataloger som normalt benyttes af plugins
>
> >Hmm! Hvilke få kataloger?
>
> Dem der er tilgængelige i "Low rights mode".

Og de er...?

> >Og får brugeren da heller ikke muligheden gennem UAP til at give
> >tilladelse?
>
> Du mener UAC? Nej. De to ting har ikke noget med hinanden at gøre.
> I Protected Mode kører IE netop *altid* i Low mode. Ellers ville
> det jo ikke være beskyttet.

Nej, jeg mener UAP - User Account Protection. User Account Control er
vist noget i Longhorn eller på en Windows server. Langt fra på en TP.

> I praksis kan man naturligvis løse det ved at gøre skat.dk til et
> "Trusted" site. Så vil rettighederne svare til brugerens normale
> rettigheder (altså, Protected Mode er slået fra).
>
> >Det lyder mærkeligt, at det skulle være udelukket.
>
> Hvad er ideen med "Protected Mode", hvis den ikke er "protected"?

Aner det ikke. Det var dig der indførte UAC.

---

"Axel Hammerschmidt" <hlexa@hotmail.com> wrote:
> Nej, jeg mener UAP - User Account Protection. User Account Control er
> vist noget i Longhorn eller på en Windows server. Langt fra på en TP.

"Windows Vista - User Account Control (UAC): Formerly User Account
Protection (UAP)"
http://www.computerperformance.co.uk/vista/user_account_protection.htm

---

hlexa@hotmail.com (Axel Hammerschmidt) writes:

>> Dem der er tilgængelige i "Low rights mode".

>Og de er...?

Se http://blogs.msdn.com/ie/archive/2005/06/14/428811.aspx

>Nej, jeg mener UAP - User Account Protection. User Account Control er
>vist noget i Longhorn eller på en Windows server. Langt fra på en TP.

"User Account Protection" findes ikke længere. Det var så at sige
beta-versionen af den teknologi, der hedder "User Account Control"
(UAC).

UAP eksisterede kun på beta-udgaver af Vista. Det eksisterer ikke
på ældre versioner af Windows (ej heller Windows XP). Den ægte
Vista kalder det for UAC.

Men UAP virkede - og UAC virker - aldeles glimrende på ThinkPads.

>> Hvad er ideen med "Protected Mode", hvis den ikke er "protected"?

>Aner det ikke. Det var dig der indførte UAC.

Det gjorde jeg netop ikke. Hverken UAP eller UAC har noget med
low rights mode at gøre.

Ideen med UAC er, at du kan køre som en almindelig bruger men i
visse situationer give tilladelse til, at du "ophøjes" til at
have administrator-privilegier.

Low rights mode betyder, at du har afgivet nogle af de rettigheder,
du har som ganske almindelig bruger. Administratorer er altså ikke
involveret, sådan som du tror, når du refererer til UAP/UAC.

Mvh.
   Klaus.

---

Jakob Bøhm skrev:
>
> På Vista er der en sikkerhedsfeature hvor hele Internet Explorer køres i
> en lukket sandkasse hvor både IE og de plugins der kaldes fra IE kun har
> adgang til nogle få Internet-relevante kataloger og registry keys.
> Herved forhindrer man hjemmesider i at gå ind og stjæle eller manipulere
> værdifulde filer som f.eks. den private nøgle til digital signatur. Man
> forhindrer også at plugins prøver at lægge filer på steder hvor de ikke
> har noget at gøre, som f.eks. direkte i %USERPROFILE%.
>
> OpenSign/OpenLogon begår den indledende fejl at forsøge at downloade
> sine indre komponenter til et sted udenfor sandkassen, og når derfor
> aldrig at blive fuldstændigt downloadet. Dermed kommer opensign slet
> ikke i gang på Vista uanset hvordan man fjerner beskyttelsen af sin
> digitale signatur.
>

Projektet har faktisk arbejdet med at få OpenSign/OpenLogon til at kører
på en Vista-maskine og lige nu har vi en release candidate (unstable
version 1.7.0) i test hvor problemet skulle være løst. ALLE er meget
velkommen til at teste den på
http://www.openoces.org/demo/index.html

Bemærk at demo-siden primært udviklet for udviklere og derfor ikke er
særlig fancy.

Bemærk desuden, at der KAN være nogle udfordringer i "jcontrolpanel
keystore", hvorfor jeg anbefaler at slå det fra.

> De fundamentale misforståelser i OpenSign/OpenLogon er dog to andre ting:
>
> 1. "Det er ikke en sikkerhedsrisiko at bruge en plugin som signerer
> arbitrær tekst med brugerens digitale signatur uden at brugeren har en
> reel mulighed for at se og tage stilling til hvad han/hun skriver under
> på" .
> Dette er oplagt forkert. Også selvom den hjemmeside der bruger den
> pågældende plugin i dag tilfældigvis bare signerer en "tom" XML-fil med
> et løbenummer for logonforsøget. For en anden hjemmeside kunne jo kalde
> den pågældende plugin med en XML-fil hvor der stod "Fortæl
> tinglysningskontoret at jeg lige har solgt mit hus for 1 kr. til hr. tyv"
>

Kan du lave et eksempel, hvor du kan bruge OpenLogon til ovenstående??

Bemærk bl.a. attributtet "VisibleToSigner" og værdien af denne i det
genererede XML.

Venlig hilsen

Peter Lind Damkjær
Deltager i OpenOCES.org projektet.

---

"Peter Lind Damkjær" <peter@lind-damkjaer.dk> wrote:
> Projektet har faktisk arbejdet med at få OpenSign/OpenLogon til at kører
> på en Vista-maskine og lige nu har vi en release candidate (unstable
> version 1.7.0) i test hvor problemet skulle være løst. ALLE er meget
> velkommen til at teste den på
> http://www.openoces.org/demo/index.html
>

Nogen ide om hvorfor der gøres mere og mere brug af disse applets? Min
browser kan alt hvad der er nødvendigt for at jeg kan identificere mig for
websites når jeg bruger mit certifikat og jeg må indrømme at være utryg ved
at lade udefrakommende kode få direkte adgang til mit certifikat.

---

Alex Holst skrev:
> Nogen ide om hvorfor der gøres mere og mere brug af disse applets? Min
> browser kan alt hvad der er nødvendigt for at jeg kan identificere mig
> for websites når jeg bruger mit certifikat og jeg må indrømme at være
> utryg ved at lade udefrakommende kode få direkte adgang til mit certifikat.
>
>

OpenOCES.org projektet hører primært disse argumenter (ikke nødvendigvis
prioritetet):

1:
Direkte understøttelse af CD-kort
(http://www.digitalsignatur.dk/visNyhed.asp?artikelID=992)

2:
Bedre mulighed for brugere for at skelne forskellige certifikater
(typisk medarbejder certifikater og personlige certifikater).

3:
Bedre mulighed for filtrering af certifikater der vises brugeren (f.eks.
kun medarbejder certifikater).

4:
Bedre håndtering af log-out funktionalitet (den traditionelle SSL holder
typisk en session).

Venlig hilsen
Peter Lind Damkjær

---

Peter Lind Damkjær wrote:
> Alex Holst skrev:
>> Nogen ide om hvorfor der gøres mere og mere brug af disse applets? Min
>> browser kan alt hvad der er nødvendigt for at jeg kan identificere mig
>> for websites når jeg bruger mit certifikat og jeg må indrømme at være
>> utryg ved at lade udefrakommende kode få direkte adgang til mit
>> certifikat.
>>
>>
>
> OpenOCES.org projektet hører primært disse argumenter (ikke nødvendigvis
> prioritetet):
>
> 1:
> Direkte understøttelse af CD-kort
> (http://www.digitalsignatur.dk/visNyhed.asp?artikelID=992)
>

Denne artikel er totalt intetsigende og tilsyneladende skrevet af de
sædvanlige reklamefolk hos TDC. Er der et sted hvor man kan læse
hvordan dette keystore egentlig fungerer og hvad der gør det
sikkert/usikkert.

> 2:
> Bedre mulighed for brugere for at skelne forskellige certifikater
> (typisk medarbejder certifikater og personlige certifikater).
>

Øh, plejer WebBrowser, mailprogram og andet standardsoftware på en given
platform ikke at være rørende enige om hvordan evtuelle valgmuligheder
præsenteres for brugeren? Altså i det tilfælde hvor man har mere end 1
signatur på samme maskine.


> 3:
> Bedre mulighed for filtrering af certifikater der vises brugeren (f.eks.
> kun medarbejder certifikater).
>

Dette er kun et problem fordi TDC har valgt et flat hierarki med en
enkelt self-signed CA som direkte signerer alting. Hvis de i stedet
lige som VeriSign havde lavet en serie intermediary CA-er (en for hver
udstedelsestype), men alle signeret af samme rod-CA kunne den slags
filtrering laves ved at angive de acceptable intermediaries i et
SSL-signaturrequest. Uanset client-side filtreringsmulighederne skal
man alligevel altid filtrere serverside.


> 4:
> Bedre håndtering af log-out funktionalitet (den traditionelle SSL holder
> typisk en session).
>

Med OpenLogon er der slet ingen log-out! Med hensyn til at begrænse
varigheden af certifikatbrugen kan man bruge en arkitektur som ligner
den hos servicefællesskabet: Når man trykker "Logon" redirectes man til
en dedikeret logonserver som checker certifikatet og signatur og straks
redirecter tilbage til f.eks. tastselv.skat.dk, hvorved sessionen afsluttes.

Yderligere hindring af gentagen logon ved hjælp af fortsættelse af en
gammel SSL-session kan klares serverside ved at serveren insisterer på
at logon-url-en skal være første request i en helt frisk session uden
key reuse.


--
Jakob Bøhm, M.Sc.Eng. * jb@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right
Mine usenet-indlæg repræsenterer IKKE firmaets holdning.

---

Jakob Bøhm skrev:
> Peter Lind Damkjær wrote:
>> Alex Holst skrev:
>>> Nogen ide om hvorfor der gøres mere og mere brug af disse applets?
>>> Min browser kan alt hvad der er nødvendigt for at jeg kan
>>> identificere mig for websites når jeg bruger mit certifikat og jeg må
>>> indrømme at være utryg ved at lade udefrakommende kode få direkte
>>> adgang til mit certifikat.
>>>
>>>
>>
>> OpenOCES.org projektet hører primært disse argumenter (ikke
>> nødvendigvis prioritetet):
>>
>> 1:
>> Direkte understøttelse af CD-kort
>> (http://www.digitalsignatur.dk/visNyhed.asp?artikelID=992)
>>
>
> Denne artikel er totalt intetsigende og tilsyneladende skrevet af de
> sædvanlige reklamefolk hos TDC. Er der et sted hvor man kan læse
> hvordan dette keystore egentlig fungerer og hvad der gør det
> sikkert/usikkert.
>

www.digitalsignatur.dk er drevet af IT- og Telestyrelsen og artiklen er
skrevet af styrelsen.

Jeg tog såmen bare linket med for at man kunne se, at dette CD-kort
bliver rullet ud generelt og at organisationer dermed kan ønske at
understøtte dette i deres logon-mekanisme. Det var ikke for at give en
egentlig spec.

CD-kortet er i store træk blot en tilskåret CD med signaturen liggende i
et format, der ligner det HTML-backupformat, som anvendes for
"almindelige" TDC software-signature. Dog er der indblandet en såkaldt
adgangskontrolserver ved anvendelse, der sikre mod udtømmende søgning af
password.

Her kommer Open Source til sin ret. Hvis du selv ønsker at analyser
sikkerheden i CD-kortet, kan du checke OpenSign-koden og se hvordan
CD-kort håndteres.

>> 2:
>> Bedre mulighed for brugere for at skelne forskellige certifikater
>> (typisk medarbejder certifikater og personlige certifikater).
>>
>
> Øh, plejer WebBrowser, mailprogram og andet standardsoftware på en given
> platform ikke at være rørende enige om hvordan evtuelle valgmuligheder
> præsenteres for brugeren? Altså i det tilfælde hvor man har mere end 1
> signatur på samme maskine.
>

Jo, men ofte skal man trykke "Detaljer" og analysere indholdet nærmere
for at finde det certifikat, man ønsker at anvende.

>
>> 3:
>> Bedre mulighed for filtrering af certifikater der vises brugeren
>> (f.eks. kun medarbejder certifikater).
>>
>
> Dette er kun et problem fordi TDC har valgt et flat hierarki med en
> enkelt self-signed CA som direkte signerer alting. Hvis de i stedet
> lige som VeriSign havde lavet en serie intermediary CA-er (en for hver
> udstedelsestype), men alle signeret af samme rod-CA kunne den slags
> filtrering laves ved at angive de acceptable intermediaries i et
> SSL-signaturrequest. Uanset client-side filtreringsmulighederne skal
> man alligevel altid filtrere serverside.
>

TDC følger blot OCES certifikatpolitikkerne (afsnit 4.1) der er
defineret af staten. Men iøvrigt mener jeg ikke, at det er i X.509v3's
ånd at styre politikker og dermed certifikattyper på CA-niveau. I stedet
bør man (som i OCES) styrer på certifikatpolitik-niveau og det er da
også denne vej verden generelt bevæger sig. Et eksempel er
EV-certifikater (www.cabforum.org). MS IE7 er faktisk policy-drevet mht.
EV-certifikater.

OCES er et skridt i samme retning.

Naturligvis skal man filtrere på serverside. Men hvis brugeren har valgt
et forkert certifikat, skal man typisk lukke browseren og starte forfra.

PS. OpenSign/OpenLogon kan filtere helt ned på certifikatets
serienummer. Dette kan typisk anvendes hvis en bruger er logget ind med
et givet certifikat og der senere skal underskrives en tekst i samme
session. (Et eksempel er Skat's videregivelse af årsopgørelser)

>
>> 4:
>> Bedre håndtering af log-out funktionalitet (den traditionelle SSL
>> holder typisk en session).
>>
>
> Med OpenLogon er der slet ingen log-out! Med hensyn til at begrænse
> varigheden af certifikatbrugen kan man bruge en arkitektur som ligner
> den hos servicefællesskabet: Når man trykker "Logon" redirectes man til
> en dedikeret logonserver som checker certifikatet og signatur og straks
> redirecter tilbage til f.eks. tastselv.skat.dk, hvorved sessionen
> afsluttes.
>

Det er korrekt at der ikke er logout i OpenLogon. Det styres i
applikationslaget (typisk via servervariable).

> Yderligere hindring af gentagen logon ved hjælp af fortsættelse af en
> gammel SSL-session kan klares serverside ved at serveren insisterer på
> at logon-url-en skal være første request i en helt frisk session uden
> key reuse.
>
>

Jeps, men visse browsere (læs IE) insisterer på at et efterfølgende
login foretages med samme certifikat. Det er træls i et scenarie, hvor
"far" godkender sin selvangivelse, hvorefter "mor" ønsker at godkende
sin selvangivelse.

/Peter

---

Peter Lind Damkjær wrote:
> Jakob Bøhm skrev:
>> Peter Lind Damkjær wrote:
>>> Alex Holst skrev:
>>>> Nogen ide om hvorfor der gøres mere og mere brug af disse applets?
>>>> Min browser kan alt hvad der er nødvendigt for at jeg kan
>>>> identificere mig for websites når jeg bruger mit certifikat og jeg
>>>> må indrømme at være utryg ved at lade udefrakommende kode få direkte
>>>> adgang til mit certifikat.
>>>>
>>>>
>>>
>>> OpenOCES.org projektet hører primært disse argumenter (ikke
>>> nødvendigvis prioritetet):
>>>
>>> 1:
>>> Direkte understøttelse af CD-kort
>>> (http://www.digitalsignatur.dk/visNyhed.asp?artikelID=992)
>>>
>>
>> Denne artikel er totalt intetsigende og tilsyneladende skrevet af de
>> sædvanlige reklamefolk hos TDC. Er der et sted hvor man kan læse
>> hvordan dette keystore egentlig fungerer og hvad der gør det
>> sikkert/usikkert.
>>
>
> www.digitalsignatur.dk er drevet af IT- og Telestyrelsen og artiklen er
> skrevet af styrelsen.
>
Men åbenbart mere af pressemedarbejderen end teknikmedarbejderen, der er
ingen links til formelle specs etc.

> Jeg tog såmen bare linket med for at man kunne se, at dette CD-kort
> bliver rullet ud generelt og at organisationer dermed kan ønske at
> understøtte dette i deres logon-mekanisme. Det var ikke for at give en
> egentlig spec.
>
OK, I orden.

> CD-kortet er i store træk blot en tilskåret CD med signaturen liggende i
> et format, der ligner det HTML-backupformat, som anvendes for
> "almindelige" TDC software-signature. Dog er der indblandet en såkaldt
> adgangskontrolserver ved anvendelse, der sikre mod udtømmende søgning af
> password.
>
Er der ikke vedlagt nogen form for CSP eller PKCS11-plugin til brug i
standard e-mail programmer, browsere etc.?

> Her kommer Open Source til sin ret. Hvis du selv ønsker at analyser
> sikkerheden i CD-kortet, kan du checke OpenSign-koden og se hvordan
> CD-kort håndteres.
>
Ikke tid... UTSL metoden er ret tidskrævende især hvis man ikke kender
kodestrukturen i forvejen.

>>> 2:
>>> Bedre mulighed for brugere for at skelne forskellige certifikater
>>> (typisk medarbejder certifikater og personlige certifikater).
>>>
>>
>> Øh, plejer WebBrowser, mailprogram og andet standardsoftware på en
>> given platform ikke at være rørende enige om hvordan evtuelle
>> valgmuligheder præsenteres for brugeren? Altså i det tilfælde hvor
>> man har mere end 1 signatur på samme maskine.
>>
>
> Jo, men ofte skal man trykke "Detaljer" og analysere indholdet nærmere
> for at finde det certifikat, man ønsker at anvende.
>

Men typisk vil man kun bliver præsenteret for de samme 2-3 certifikater,
hvis identitet man så efterhånden kender udenad. Nogle systemer (bl.a.
I.E., Outlook etc.) lader også brugeren giver certifikaterne huske-navne.

>>
>>> 3:
>>> Bedre mulighed for filtrering af certifikater der vises brugeren
>>> (f.eks. kun medarbejder certifikater).
>>>
>>
>> Dette er kun et problem fordi TDC har valgt et flat hierarki med en
>> enkelt self-signed CA som direkte signerer alting. Hvis de i stedet
>> lige som VeriSign havde lavet en serie intermediary CA-er (en for hver
>> udstedelsestype), men alle signeret af samme rod-CA kunne den slags
>> filtrering laves ved at angive de acceptable intermediaries i et
>> SSL-signaturrequest. Uanset client-side filtreringsmulighederne skal
>> man alligevel altid filtrere serverside.
>>
>
> TDC følger blot OCES certifikatpolitikkerne (afsnit 4.1) der er
> defineret af staten. Men iøvrigt mener jeg ikke, at det er i X.509v3's
> ånd at styre politikker og dermed certifikattyper på CA-niveau. I stedet
> bør man (som i OCES) styrer på certifikatpolitik-niveau og det er da
> også denne vej verden generelt bevæger sig. Et eksempel er
> EV-certifikater (www.cabforum.org). MS IE7 er faktisk policy-drevet mht.
> EV-certifikater.
>
At signere certifikater med forskellig policy med samme higher-level CA
og så tro blindt på at ALLE eksisterende X.509 applikationer gør det let
at sætte forskellige trust-niveauer e.l. udfra finkornet filtrering på
X.509 attributter i certifikater er meget naivt og virkelighedsfjernt.

F.eks. kan man i I.E./CryptoAPI manuelt konfigurere trust-niveauet pr.
certifikat (enkeltcertifikat eller CA certifikat), men ikke sige f.eks.
"Trust certificates signed by TDC OCES CA with attribute OID 1.2.3.4=
OID 5.6.7.8 for e-mail signing".

De begrænsede filtreringsmuligheder i SSL/TLS er et andet eksempel.

> OCES er et skridt i samme retning.
>

OCES specifikationen indeholder mange fjollede og antiproduktive
detaljer, f.eks. står der også at OCES rod-certifikatet IKKE må være
krydscertificeret af andre CA-er, f.eks. en af de internationalt
anerkendte root-CA-er. Dette betød at slutbrugere i de første par år
manuelt måtte installere OCES-rodcertifikater via en two-channel metode
som bare havde et sikkerhedshul fordi telefonnummeret til verifikation
kun stod på den side der skulle kontrolleres, men IKKE i telefonbogen!
(Problemet gik over da TDCs OCES-rod efter nogle års turn-around kom med
i de fleste CA-bundles fra MS, Mozilla, m.fl.)

> Naturligvis skal man filtrere på serverside. Men hvis brugeren har valgt
> et forkert certifikat, skal man typisk lukke browseren og starte forfra.
>
> ...
>
> Jeps, men visse browsere (læs IE) insisterer på at et efterfølgende
> login foretages med samme certifikat. Det er træls i et scenarie, hvor
> "far" godkender sin selvangivelse, hvorefter "mor" ønsker at godkende
> sin selvangivelse.
>
Jeg var ikke klar over denne bug.

En workaround i ramte applikationer kunne måske (ikke testet) være at
give login-serveren mere end et DNS-navn (f.eks. via *-alias) og så lade
loginsiten placere sin sessionscookie-værdi som første led, f.eks.

gfjfdsahgushgdshgf723kfsd.login2.servicefaellesskabet.dk

På den måde narres broseren (måske) til ikke at genbruge det gamle valg.
Servercertifikatet skal selvfølgelig så også være et tilsvarende
stjernecertifikat.



--
Jakob Bøhm, M.Sc.Eng. * jb@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right
Jeg udtaler mig her som privatperson.

---

Peter Lind Damkjær wrote:
>
> Jakob Bøhm skrev:
>>
>> På Vista er der en sikkerhedsfeature hvor hele Internet Explorer køres
>> i en lukket sandkasse hvor både IE og de plugins der kaldes fra IE kun
>> har adgang til nogle få Internet-relevante kataloger og registry keys.
>> Herved forhindrer man hjemmesider i at gå ind og stjæle eller
>> manipulere værdifulde filer som f.eks. den private nøgle til digital
>> signatur. Man forhindrer også at plugins prøver at lægge filer på
>> steder hvor de ikke har noget at gøre, som f.eks. direkte i
>> %USERPROFILE%.
>>
>> OpenSign/OpenLogon begår den indledende fejl at forsøge at downloade
>> sine indre komponenter til et sted udenfor sandkassen, og når derfor
>> aldrig at blive fuldstændigt downloadet. Dermed kommer opensign slet
>> ikke i gang på Vista uanset hvordan man fjerner beskyttelsen af sin
>> digitale signatur.
>>
>
> Projektet har faktisk arbejdet med at få OpenSign/OpenLogon til at kører
> på en Vista-maskine og lige nu har vi en release candidate (unstable
> version 1.7.0) i test hvor problemet skulle være løst. ALLE er meget
> velkommen til at teste den på
> http://www.openoces.org/demo/index.html
>
> Bemærk at demo-siden primært udviklet for udviklere og derfor ikke er
> særlig fancy.
>
> Bemærk desuden, at der KAN være nogle udfordringer i "jcontrolpanel
> keystore", hvorfor jeg anbefaler at slå det fra.
>
>> De fundamentale misforståelser i OpenSign/OpenLogon er dog to andre ting:
>>
>> 1. "Det er ikke en sikkerhedsrisiko at bruge en plugin som signerer
>> arbitrær tekst med brugerens digitale signatur uden at brugeren har en
>> reel mulighed for at se og tage stilling til hvad han/hun skriver
>> under på" .
>> Dette er oplagt forkert. Også selvom den hjemmeside der bruger den
>> pågældende plugin i dag tilfældigvis bare signerer en "tom" XML-fil
>> med et løbenummer for logonforsøget. For en anden hjemmeside kunne jo
>> kalde den pågældende plugin med en XML-fil hvor der stod "Fortæl
>> tinglysningskontoret at jeg lige har solgt mit hus for 1 kr. til hr. tyv"
>>
>
> Kan du lave et eksempel, hvor du kan bruge OpenLogon til ovenstående??
>
> Bemærk bl.a. attributtet "VisibleToSigner" og værdien af denne i det
> genererede XML.
>

Ok, ved brug af demosiden så det ud til at html-koden ikke selv kan
bestemme XML-indpakningen af teksten, og derfor måske ikke kan hindre at
skjult tekst markeres som "VisibleToSigner='no'" . Bortset herfra var
det trivielt at skrive end valgfri besked i tekstfeltet.

Denne sikkerhedsforanstaltning er dog ikke særligt synlig udadtil, den
er f.eks. ikke omtalt i dokumentationen!



--
Jakob Bøhm, M.Sc.Eng. * jb@danware.dk * direct tel:+45-45-90-25-33
Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARK
http://www.netop.com * tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
Information in this mail is hasty, not binding and may not be right

---

Jakob Bøhm <jb@danware.dk> crashed Echelon writing
news:465c4e0d$0$14021$edfadb0f@dread15.news.tele.dk:

> Konkret gætter jeg på at du kører Internet Explorer under Vista. Lige
> præcis denne kombination af operativsystem og browser indeholder en
> effektiv beskyttelse mod browserplugins der prøver at få fat på ting
> uden for browseren, herunder den omtalte opensign plugin (som er noget
> af den slags der SKAL standses af et godt sikkerhedssystem).

Lad os nu se hvad John svarer, han postede trods alt fra en XP maskine.

--
Bjarke Andersen

---

On 4 Jun., 11:44, Jakob Bøhm <j...@danware.dk> wrote:
> Peter Lind Damkjær wrote:
> > Jakob Bøhm skrev:
> >> Peter Lind Damkjær wrote:
> >>> Alex Holst skrev:
> >>>> Nogen ide om hvorfor der gøres mere og mere brug af disse applets?
> >>>> Min browser kan alt hvad der er nødvendigt for at jeg kan
> >>>> identificere mig for websites når jeg bruger mit certifikat og jeg
> >>>> må indrømme at være utryg ved at lade udefrakommende kode få direkte
> >>>> adgang til mit certifikat.
>
> >>> OpenOCES.org projektet hører primært disse argumenter (ikke
> >>> nødvendigvis prioritetet):
>
> >>> 1:
> >>> Direkte understøttelse af CD-kort
> >>> (http://www.digitalsignatur.dk/visNyhed.asp?artikelID=992)
>
> >> Denne artikel er totalt intetsigende og tilsyneladende skrevet af de
> >> sædvanlige reklamefolk hos TDC. Er der et sted hvor man kan læse
> >> hvordan dette keystore egentlig fungerer og hvad der gør det
> >> sikkert/usikkert.
>
> >www.digitalsignatur.dker drevet af IT- og Telestyrelsen og artiklen er
> > skrevet af styrelsen.
>
> Men åbenbart mere af pressemedarbejderen end teknikmedarbejderen, der er
> ingen links til formelle specs etc.
>
> > Jeg tog såmen bare linket med for at man kunne se, at dette CD-kort
> > bliver rullet ud generelt og at organisationer dermed kan ønske at
> > understøtte dette i deres logon-mekanisme. Det var ikke for at give en
> > egentlig spec.
>
> OK, I orden.
>
> > CD-kortet er i store træk blot en tilskåret CD med signaturen liggende i
> > et format, der ligner det HTML-backupformat, som anvendes for
> > "almindelige" TDC software-signature. Dog er der indblandet en såkaldt
> > adgangskontrolserver ved anvendelse, der sikre mod udtømmende søgning af
> > password.
>
> Er der ikke vedlagt nogen form for CSP eller PKCS11-plugin til brug i
> standard e-mail programmer, browsere etc.?
>
> > Her kommer Open Source til sin ret. Hvis du selv ønsker at analyser
> > sikkerheden i CD-kortet, kan du checke OpenSign-koden og se hvordan
> > CD-kort håndteres.
>
> Ikke tid... UTSL metoden er ret tidskrævende især hvis man ikke kender
> kodestrukturen i forvejen.
>
> >>> 2:
> >>> Bedre mulighed for brugere for at skelne forskellige certifikater
> >>> (typisk medarbejder certifikater og personlige certifikater).
>
> >> Øh, plejer WebBrowser, mailprogram og andet standardsoftware på en
> >> given platform ikke at være rørende enige om hvordan evtuelle
> >> valgmuligheder præsenteres for brugeren? Altså i det tilfælde hvor
> >> man har mere end 1 signatur på samme maskine.
>
> > Jo, men ofte skal man trykke "Detaljer" og analysere indholdet nærmere
> > for at finde det certifikat, man ønsker at anvende.
>
> Men typisk vil man kun bliver præsenteret for de samme 2-3 certifikater,
> hvis identitet man så efterhånden kender udenad. Nogle systemer (bl.a.
> I.E., Outlook etc.) lader også brugeren giver certifikaterne huske-navne.
>
>
>
>
>
> >>> 3:
> >>> Bedre mulighed for filtrering af certifikater der vises brugeren
> >>> (f.eks. kun medarbejder certifikater).
>
> >> Dette er kun et problem fordi TDC har valgt et flat hierarki med en
> >> enkelt self-signed CA som direkte signerer alting. Hvis de i stedet
> >> lige som VeriSign havde lavet en serie intermediary CA-er (en for hver
> >> udstedelsestype), men alle signeret af samme rod-CA kunne den slags
> >> filtrering laves ved at angive de acceptable intermediaries i et
> >> SSL-signaturrequest. Uanset client-side filtreringsmulighederne skal
> >> man alligevel altid filtrere serverside.
>
> > TDC følger blot OCES certifikatpolitikkerne (afsnit 4.1) der er
> > defineret af staten. Men iøvrigt mener jeg ikke, at det er i X.509v3's
> > ånd at styre politikker og dermed certifikattyper på CA-niveau. I stedet
> > bør man (som i OCES) styrer på certifikatpolitik-niveau og det er da
> > også denne vej verden generelt bevæger sig. Et eksempel er
> > EV-certifikater (www.cabforum.org). MS IE7 er faktisk policy-drevet mht.
> > EV-certifikater.
>
> At signere certifikater med forskellig policy med samme higher-level CA
> og så tro blindt på at ALLE eksisterende X.509 applikationer gør det let
> at sætte forskellige trust-niveauer e.l. udfra finkornet filtrering på
> X.509 attributter i certifikater er meget naivt og virkelighedsfjernt.
>
> F.eks. kan man i I.E./CryptoAPI manuelt konfigurere trust-niveauet pr.
> certifikat (enkeltcertifikat eller CA certifikat), men ikke sige f.eks.
> "Trust certificates signed by TDC OCES CA with attribute OID 1.2.3.4=
> OID 5.6.7.8 for e-mail signing".
>
> De begrænsede filtreringsmuligheder i SSL/TLS er et andet eksempel.
>
> > OCES er et skridt i samme retning.
>
> OCES specifikationen indeholder mange fjollede og antiproduktive
> detaljer, f.eks. står der også at OCES rod-certifikatet IKKE må være
> krydscertificeret af andre CA-er, f.eks. en af de internationalt
> anerkendte root-CA-er. Dette betød at slutbrugere i de første par år
> manuelt måtte installere OCES-rodcertifikater via en two-channel metode
> som bare havde et sikkerhedshul fordi telefonnummeret til verifikation
> kun stod på den side der skulle kontrolleres, men IKKE i telefonbogen!
> (Problemet gik over da TDCs OCES-rod efter nogle års turn-around kom med
> i de fleste CA-bundles fra MS, Mozilla, m.fl.)
>
> > Naturligvis skal man filtrere på serverside. Men hvis brugeren har valgt
> > et forkert certifikat, skal man typisk lukke browseren og starte forfra.
>
> > ...
>
> > Jeps, men visse browsere (læs IE) insisterer på at et efterfølgende
> > login foretages med samme certifikat. Det er træls i et scenarie, hvor
> > "far" godkender sin selvangivelse, hvorefter "mor" ønsker at godkende
> > sin selvangivelse.
>
> Jeg var ikke klar over denne bug.
>
> En workaround i ramte applikationer kunne måske (ikke testet) være at
> give login-serveren mere end et DNS-navn (f.eks. via *-alias) og så lade
> loginsiten placere sin sessionscookie-værdi som første led, f.eks.
>
> gfjfdsahgushgdshgf723kfsd.login2.servicefaellesskabet.dk
>
> På den måde narres broseren (måske) til ikke at genbruge det gamle valg.
> Servercertifikatet skal selvfølgelig så også være et tilsvarende
> stjernecertifikat.
>
> --
> Jakob Bøhm, M.Sc.Eng. * j...@danware.dk * direct tel:+45-45-90-25-33
> Danware Data A/S * Bregnerodvej 127 * DK-3460 Birkerod * DENMARKhttp://www.netop.com* tel:+45-45-90-25-25 * fax tel:+45-45-90-25-26
> Information in this mail is hasty, not binding and may not be right
> Jeg udtaler mig her som privatperson.

Denne diskussion er kommet lidt langt væk fra sit udgangspunkt

Det beskrevne problem "Unable to create zip cache dir C:\Documents and
Settings\mitbrugernavn\.oces\opensign\plugins" har jeg oplevet på en
tilsvarende T60p maskine. Om det er IBM's software skal jeg ikke kunne
sige.

Mere interessant er det, at nøjagtig det samme problem opstår i
Firefox. Jeg kan se, at der bliver oprettet en ./oces folder, som
absolut ingen må læse og skrive i (oversat til unix permissions er det
d--------- eller 000). Det sker i XP og noget ligende på OSX så vidt
jeg husker. Det er altså ikke et isoleret IE problem.

Tør nogen gætte på, hvad årsagen er?

MVH Christian