security - Why does Chrome hate self-signed certificates so much? -


i'm running small web app on ec2 instance , want friends able use it. want make use https, basic security purposes (prevent packet snooping whenever possible). of course using self-signed certificate, because budget project $0. chrome throws warning page upon trying visit it:

your connection not private

attackers might trying steal information [...] (for example, passwords, messages, or credit cards). net::err_cert_authority_invalid

this server not prove [...]; security certificate not trusted computer's operating system. may caused misconfiguration or attacker intercepting connection.

is not true "any encryption better no encryption"? on unenecrypted http, trying steal information well, , don't have prove server identity, , communication can read in plaintext packet sniffing, chrome doesn't throw warning flags there...

what gives? why chrome hate self-signed certificates much? why doesn't put little red box on padlock icon, instead of giving me two-click warning page?

this question not specific chrome. firefox , other browsers behave similar , in last years warnings got stricter. complaining these warnings shows more missing understanding of role of certificates in https.

with https 1 expects encryption, i.e. private communication between browser , server nobody sniffing or manipulating transferred data. @ beginning of encryption client , server exchange encryption keys, 1 can encrypt data , other can decrypt data. if man-in-the-middle manages manipulate key exchange in way gets control on encryption keys, connection still encrypted not private. essential key exchange protected , done certificates. proper checking of certificates client can verify talks server , not man-in-the-middle , critical key exchange can protected.

certificates verified by

  • checking trust chain, i.e. if certificate directly or indirectly (via immediate certificates) issued certificate agency (ca) trusted browser or operating system.
  • verifying certificate issued expected hostname, i.e. subject matches hostname.

with self-signed certificates or certificates issued ca unknown browser/os check fail. in case unknown, if original certificate not issued trusted ca or if there man-in-the-middle manipulating connection. being man-in-the-middle not hard, in unprotected networks public hotspots.

because browser can not verify certificate in cases throw big fat warning show user wrong. if friends know have self-signed certificate there should know expected behavior of browser in case. should provide them fingerprint of certificate can sure expected certificate - because there no other way check validity of certificate. note warning comes once because browser saves fingerprint , on knows site associated certificate. if change certificate complain again.

if don't trouble of teaching of friends how verify certificate certificate public ca. don't need expensive , issue free certificates.

is not true "any encryption better no encryption"?

while bad encryption might better no encryption, transferring sensitive data on en encrypted man-in-the-middle connection worse transferring non-sensitive data no encryption. , contrary plain http can detect potential man-in-the-middle attack https. can not find out if potential man-in-the-middle attack or if non-verifiable certificate expected, because browser has no previous knowledge expect. self-signed certificate not bad provided browser knows up-front site provides self-signed certificate. , might not bad if transferred data not sensitive. how should browser know kind of data , kind of certificate expect?


Comments

Popular posts from this blog

qt - Using float or double for own QML classes -

Create Outlook appointment via C# .Net -

ios - Swift Array Resetting Itself -