Hetenre lejáró SSL certificate Gmail esetén

Security-all

A címben a probléma. Ez normális, ennek így kell lennie? Nézem, december 28-ig lett volna érvényes, a következő január 5-ig, persze, már most megújítják. Ez ilyen, ezzel együtt kell élni?

Hetente nézegessek fingerprintet, vagy hetente reménykedjek, hogy nem vagyok hamis certtel egy MITM támadás áldozata?

( trey | 2015. 10. 14., sze – 10:21 )

Nem tudom, hogy ez mennyire probléma. Én még nem találkoztam lejárt tanúsítvánnyal a Gmail-en. A normálisabb böngészők ugatnak ha lejárt a tanúsítvány, nem? Miért kellene azt neked nézegetned?

--
trey @ gépház

Nem böngésző, levelező, azon belül is Claws-Mail. Igen, szól, megkérdezi, hogy mentse-e az újat.

Bevallom műveletlen vagyok a témában, de a tanúsítványnak nem az a lényege, hogy egyszer megnéztem, rendben van, utána nincs dolgom vele, mert az ellenőrzésre kerül a mentés alapján? A gyakori cserével az a gondom, hogy szerintem épp ez a melegágya annak, hogy hamisított certet mentve nem ahhoz a szerverhez kapcsolódom, amelyikhez hiszem, hogy kapcsolódtam.

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

A Firefox és Thunderbird csak akkor, szól ha bibi van a tanúsítvánnyal azért nem, hogy eddig régi volt és új lett.

Egyébként úgy tűnik a claws-ba is van rá opció:

9th June 2014 Claws Mail 3.10.1
CLAWS MAIL RELEASE NOTES
http://www.claws-mail.org
Claws Mail is a GTK+ based, user-friendly, lightweight, and fast
email client.
New in this release:

* Add an account preference to allow automatically accepting
unknown and changed SSL certificates, if they're valid (that is,
if the root CA is trusted by the distro).

Amit ő nem ismer (nincs még mentve :)) 


	if (accept_if_valid)
		valid = ssl_certificate_is_valid(current_cert, status);
	else
		valid = FALSE; /* Force check */

	if (known_cert == NULL) { 
		if (valid) {
			ssl_certificate_save(current_cert);
			ssl_certificate_destroy(current_cert);
			return TRUE;
		}

		cert_hook_data.cert = current_cert;
		cert_hook_data.old_cert = NULL;
		cert_hook_data.expired = FALSE;
		cert_hook_data.accept = FALSE;

		hooks_invoke(SSLCERT_ASK_HOOKLIST, &cert_hook_data);

		if (!cert_hook_data.accept) {
			ssl_certificate_destroy(current_cert);
			return FALSE;
		} else {
			ssl_certificate_save(current_cert);
			ssl_certificate_destroy(current_cert);
			return TRUE;
		}
	} else ....

Képes voltál megkeresni a forrásában? :)

Na jó, akkor most mi a helyes eljárás? Ha az automatikus accept elé pipát teszek, az biztonságos eljárás, vagy ez azt jelenti, hogy akaratomon kívül rábólintottam egy esetleges immáron észrevétlen MITM támadásra?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( micsa v | 2015. 10. 14., sze – 10:21 )

a hivatalos módja a dolognak: nem fingerprintet nézni, hanem issuert.

( hawk | 2015. 10. 14., sze – 10:35 )

Azért kíváncsi lennék, hogy mi a koncepciója annak, hogy egy 2015.09.29. 21:14:35 dátummal kiállított cert 2015.12.28. 01:00:00 dátummal lejár.
Biztos van valami értelme és lényege csak nem tudjuk mi az.

Jól értem, hogy arról lehet szó, kellően nagy számítási kapacitással már belátható idő alatt hamisítható lenne, ezért lejár, mielőtt hamisíthatnák? Aztán áttérnek biztonságosabb, nehezebben törhető megoldásra?

tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

( ricsip v | 2015. 10. 14., sze – 16:51 )

Napi sokmilliárd TLS sessiön-ben hasnzálják ezeket a kulcsokat, ezért a titkosszolgálatok statisztikai alapon lehallgatással talán meg tudnák tippelni a privát kulcsot brute force-nál jóval gyorsabban. Illetve ha vki felnyomná vmelyik szerverüket, ne használhassa nagyon sokáig a cert-et. Gondolom ezek az okai.
--
WP8.x kritika: http://goo.gl/udShvC

( joco01 v | 2015. 10. 14., sze – 19:22 )

Amúgy mi értelme van, hogy változás esetén szól? Úgyis teljesen védtelen vagy, hacsak nem kapod meg a Google-től személyesen külön csatornán a jó thumbprintet.

--