Tia...
Supported Server Cipher(s): Accepted SSLv3 128 bits RC4-SHA Accepted SSLv3 128 bits RC4-MD5 Accepted SSLv3 112 bits DES-CBC3-SHA Accepted TLSv1.0 128 bits RC4-SHA Accepted TLSv1.0 128 bits RC4-MD5 Accepted TLSv1.0 112 bits DES-CBC3-SHA
...a w tlssocket.cpp (już od pewnego czasu):
char const ciphers[] = "SECURE256:+SECURE128:-ARCFOUR-128:-3DES-CBC:-MD5:+SIGN-ALL:-SIGN-RSA-MD5:+CTYPE-X509:-CTYPE-OPENPGP:-VERS-SSL3.0";
Trzy, cztery: dzię-ku-je-my!
2. Czy to jest dobry pomysł by wciąż serwer oferował (tylko) takie szyfry?
3. Czy to jest dobry pomysł, by dopuszczalne szyfry zapisać na sztywno w kodzie?
2. Skandal
3. Czemu nie. Sprawa autora. Ważne, żeby wybór był aktualny, na jakiś podstawach i udokumentowany.
I mysle, ze liczba użytkowników home.pl i filezilli jest na tyle różną, ze jeśli nie ma merytorycznych podstaw do niewspolpracowania, to pierwszy powinien zadbać o współpracę z drugim.
W założeniu zdefiniowanie takiej a nie innej listy dopuszczalnych szyfrów miało poprawić bezpieczeństwo użytkowników. Tylko jeśli nagle program przestaje się łączyć z serwerem (i nie mamy wpływu na konfigurację serwera), to efektem może być:
- powrót do ostatniej działającej wersji programu (która może mieć inne dziury);
- przejście na nieszyfrowany FTP.
Chyba jednak wolę te ataki na RC4 czy CBC niż wysyłanie haseł otwartym tekstem...