Hot answers tagged

56

The decision on whether to use HTTP or HTTPS is the client's. If the user goes directly to http://example.com, an attacker could simply hijack that connection and perform a man-in-the-middle attack. If the user goes directly to https://example.com, then the attacker must spoof the SSL/TLS connection somehow; doing so without showing the user an invalid ...


15

Browsers do not accept verification from just any third party; if they did the whole exercise would indeed be pointless. In order to be accepted as valid, the certificate presented by the website must be digitally signed by a trusted certificate authority. The default list of trusted certificate authorities, which you can see in Chrome by going to Settings-&...


12

No, the DNS lookup does not tell the client if it should connect via HTTP or HTTPS. The browser decides that - if you enter an HTTP URL it will request without TLS on port 80, and if you enter an HTTPS one it will request with TLS on port 443. So it is the client, and not the server, that decides. If the server gets a request over a protocol it does not ...


6

Figuring out if any device has been hacked is an extremely complex subject. In most cases, unless you know precisely what to look for or have weird side-effects of the hack, you may never notice it. Duct tape on camera lens will most definitely prevent anyone from seeing you. You'd obviously need to cover both cameras on a mobile phone. Other than that, ...


4

The way certificates work is that a certificate is sent by the web site to your computer. Your browser reads the certificate, looking for the identity of the "signing certificate." It then validates the signature of the downloaded certificate was created by the signing certificate. If the signing certificate is signed by itself, it is called a trusted ...


4

In order for that to succeed the server's hostname would have to match the certificate name. That means you would have to either get a CA to issue a cert as google.com (not likely to happen) or you would have to get a root cert from a CA you control and install that on the user's computer as a trusted CA certificate. Even then, many big web sites use ...


4

I wonder if it works if a website uses public key pinning? Yes it does. A certificate which is signed by a CA which was explicitly added to the trust store will not be affected by the pinning checks. This is deliberately done to allow useful and legal SSL interception. Such interception can be found in most enterprise firewalls but also lots of desktop AV ...


4

First of all I think the biggest thing that OP missed is that SSL/TLS negotiation happens first. Only AFTER safe connection is negotiated and validated, there can be any HTTP communication. HTTPS is a big misnomer, it's just your plain old HTTP only sent over completely independent SSL/TLS. If the real site has an SSL/TLS certificate, would that stop the ...


4

The behaviour of HSTS is variable depending on whether the includeSubdomains directive is applied. In the case of HSTS without includeSubDomains, a user visiting www.facebook.com wouldn't protect them if they accidentally went to ww.facebook.com without an explicit HTTPS prefix. However, when the includeSubDomains directive is applied, visiting any subdomain ...


3

Snapchat used to use a famously weak crypto implementation with a global key stored in the source code to encrypt pictures at rest, so they are infamous when it comes to security. But, luckily enough, all communication is over HTTPS. That means the owner of the network (your company) can not MitM the users (your friend) and read the content of their ...


2

You are correct on your first statement. Unless s/he is a trusted CA, your browser will still bitch that the cert is not trusted. And you'll know you're being MiTM'd. For the second paragraph, you're reaching a bit.The hacker would have to compromise DNS for ALL CAs and have a way to validate the bogus certs. Highly unlikely.


2

A not properly configured server can actually make you vulnerable to DROWN, let me show you how. As illustrated in DROWN's original website in order to be vulnerable, one of these 2 conditions has to be met: The server allows SSLv2 connections. This is surprisingly common, due to misconfiguration and inappropriate default settings. Our ...


2

You cannot defend against this. What you have described is a totally pwned computer. The only thing to do is wipe and reformat. In general, you cannot do anything sensitive on a compromised or potentially compromised computer. So don't worry about this. Make your app secure from network attacks and let the user determine whether their computer is secure.


2

Good webcams have a built-in feature that turns on the light whenever the camera is active specifically so you can't trick someone into thinking the camera isn't recording when it actually is. If it were done securely, that would be entirely in hardware, so that it can't be bypassed with software. Now, as to whether or not that's actually the case, it may ...


2

When checking quickly, I saw several instances of the exact opposite issue: Kaspersky blocking any connection to user's router's IP. The most probable explanation is that Kaspersky actually blocks known malicious IPs (given that you use the right product, ie. at least Kaspersky Internet Security and no the standalone anti-virus), but with two main ...


1

Q1 It depends on the sophistication of the attack. For a user of the device it would be difficult to perform an after-the-fact analysis, however there are examples of software that warn user in real time that some other software is using the camera. One such commercial solution for Mac is Micro Snitch. But these measures can be disabled by a prepared ...


1

Allowing a user to add trusted roots to your app might be an option. This should be easier than guiding them through whitelisting your app with Avast, because you'll be able to design the user interface to help the user complete this task. This also has the advantage that your product will be compatible with corporate networks where they often MITM ...


1

There is no way to do this in a completely secure way, since you can not trust the client. The server can never know if the user actually watched the video or not. I would advice against trying to obfuscate your code or making this to complicated - in the end a determined user will always be able to cheat anyway, and you are just making a mess of your code ...


1

If a site is affected by the DROWN attack only depends on the setup of the server serving this site, not on any relation to other servers. Thus if your server is configured to not support SSLv2 it should not be affected by the DROWN attack. Which means that either the report is wrong or your site has a different than expected setup or the outside DNS ...


1

I've had good success with the following Android proxifiers: ProxyDroid Postern ProxyDroid has one draw-back; your phone must be rooted. To the best of my knowledge Postern will work on an un-rooted phone.



Only top voted, non community-wiki answers of a minimum length are eligible