On 21.01.2009, porneL <n...@p...net> wrote:
> On Wed, 21 Jan 2009 10:45:24 -0000, Wiktor Zychla <u...@n...com.eu> wrote:
>
>> chciałbym upewnić się, że nie ma innych możliwości niż te wskazane
>> przeze mnie poniżej (w sensie "tak to się właśnie robi").
>>
>> scenariusz: strona uruchomiona w przeglądarce, w której użytkownik
>> cośtam w formanty html sobie powpisywał. skądinąd użytkownik ma w
>> systemie (przeglądarce) zainstalowany certyfikat do podpisu
>> elektronicznego i nieistotne jest skąd ma ten certyfikat ani czy jest on
>> kwalifikowany.
>
> Po pierwsze *musisz* użyć SSL (https). Nie da się tego zastąpić żadnymi JSami,
Flashami, ani Javą/ActiveX o ile nie wyedukujesz użytkowników, że muszą koniecznie
weryfikować certyfikaty Javy/AX.

I mówi to nie-ekspert (<o...@a...local>).

> Bez https można przeprowadzić atak MITM i zanim strona dotrze do twoich
użytkowników, całkowicie usunąć z niej wszelką kryptografię albo dodać skrypty, które
wysyłają atakującemu niezaszyfrowaną kopię, podmieniają dane przed podpisaniem, etc.

I co to da, jeśli serwer oczekuje podpisanych danych albo wręcz samego
podpisu i weryfikuje czy dostał co trzeba? A jeśli dane nie są wrażliwe
na ujawnienie i mogą iść bez SSL (bo jeśli by były wrażliwe, to SSL tak
czy siak by był zaprzęgnięty dla szyfrowania transmisji), to jaką
wartość będzie miało niepotrzebne zabezpieczenie szyfrowaniem?

> Jeśli chesz uwierzytelnianie klientów za pomocą certyfikatów, to SSL w obecnych
przeglądarkach to obsługuje standardowo.

Skąd pomysł że Wiktor potrzebuje uwierzytelniać klienta? Jak Wiktora
znam, to przemyślał sprawę i jeśli potrzebny mu podpis cyfrowy, to
certyfikat kliencki dla SSL *nie wystarczy* i *musi być* podpis cyfrowy.


A tak na marginesie, łamałbyś wiersze przy jakiejś przyzwoitej długości,
na przykład 72 znaków.

--
Secunia non olet.
Stanislaw Klekot