That is pretty much a dupe of the linked one.
– SmokeDispenserMar 30 '16 at 7:40

2

@SmokeDispenser There is perhaps some overlap, but the linked question (and the answers) seems to deal with server side configuration. The way I read this question, it is more about the client side consequences of the warning. As such, I think this deserves it's own set of answers, as the answers in the linked question are more technically complicated.
– KjartanMar 30 '16 at 8:30

1

@SmokeDispenser may be this topic is quiet easy for you to understand but same is not true in my case. I hope you guide me with some more relevant comments rather.
– dev grMar 30 '16 at 8:42

1

(Mostly as answered) TLS1.0, RSA, and 3DES are not state-of-the-art best-practice, but are acceptable for now and probably some years yet, assuming RSA key is big enough (and to have valid cert from Symtantec it should be at least 2048). I'm actually more worried about nonsupport of renegotation (meaning rfc5746); practically everybody fixed that in 2010, implying this server is using at least some software that is way old, and old software tends to have vulnerabilites that aren't visible on basic handshake. If server is public ssllabs.com/ssltest tests for some other problems.
– dave_thompson_085Mar 31 '16 at 1:54

using SHA1 is okayish right now but expecected to be broken any time, hence there is the SHA2 family available for quite some time already.

Question 2

Well, the developers of Chrome chose to accept this and show a green lock instead of a yellow one (connection established with warnings) for now, as otherwise a lot of sites (banks for example) would fail to show the green lock.

While using that exact combination is not ideal, it's still able to establish a connection, verify the remote machine and the exchanged data is reasonably safe (for now, at least, see forward secrecy link above).

As to how this is established: there is a handshake taking place between the browser and the server, agreeing on a specific cipher suite. Your browser and that server agreed on this one (because either might not support anything newer), even if it's not the best option. See the How does TLS work for good coverage on that.

Thanks for demystifying it! What I understood is that Chrome latch on to older cipher suit and TLS 1.0 to establish secure connection and shows a Green Lock on address bar, is it correct?
– dev grMar 30 '16 at 9:05

Well, there is a handshake taking place between the browser and the server, agreeing on a specific cipher suite. Your browser and that server agreed on this one (because either might not support anything newer), even if it's not the best option. Still way better than plain text.
– SmokeDispenserMar 30 '16 at 9:09

SHA1 is considered at risk for collision (and thus certificate signature) but not HMAC which doesn't actually need collision resistance. That said, it's easier to explain 'SHA1-never' to managers and other nontechnical people than 'SHA1-only-here-not-there'.
– dave_thompson_085Mar 31 '16 at 1:56

I'm no cryptography expert, but if my understanding is correct, the consequences of what you are seeing are in short, as follows:

Your connection is in fact, encrypted, and as such, should be safer than no encryption at all. Someone sniffing your network, or watching your traffic, should in theory only see encrypted data.

That said, the implementation of encryption that is used for this particular connection is outdated, and could have weaknesses. Why is this happening? I'm not sure. Perhaps because either the server you are connecting to, or your browser, only supports TLS 1.0. This is a little interesting in itself, if the domain name is correct (example.com). When I go to https://example.com myself, I can see it using TLS 1.2 in my browser.

It could in theory be the result of some kind of attack, which forces your browser to use an older encryption standard, so as to be able to exploit vulnerabilities that have been fixed in newer standards, but I would be very careful about jumping to conclusions (assuming you are more or less an average user, and not a particularly interesting target for any reason).

Disableing those might prevent downgrade attacks but also might keep you from using sites that (for whatever stupid reason) still only offer TLS 1.0 you may actually need to use.
– SmokeDispenserMar 30 '16 at 9:06

Kjartan, I got your point. Something is better than nothing, so Chrome uses older cipher suits and TLS 1.0 to secure connection instead of carrying out communication on a non-secured channel. Disabling it from client side would not be a great idea as SmokeDispenser explained rather one should upgrade the server.
– dev grMar 30 '16 at 9:21

That is probably a reasonable conclusion. I'm still curious about why you get 1.0 there though, if example.com really is the server you are connected to. Is your browser very old? Unless I'm missing something, your browser and the server are supposed to agree on the highest mutually supported version of TLS, but that doesn't seem to be what is occurring here...
– KjartanMar 30 '16 at 9:59

1

Sorry for the confusion, example.com is just a placeholder I put on screenshot image to hide original host from public.
– dev grMar 30 '16 at 11:28