Tag Info

Hot answers tagged

17

This client behavior is prohibited by section 8.1 of the RFC: If an HTTP response is received over insecure transport, the UA MUST ignore any present STS header field(s). The spec prohibits severs from sending insecure HSTS directives and clients from processing insecure HSTS directives. This ensures that a faulty implementation in either a server or ...


9

No. There's no such thing as a message sent from https://example.com to anywhere; a message is sent from a device, not a URL. A user visiting your site sends messages from their computer to your server, and your server sends messages to their computer; the https in the URL means that they initiated that connection with the HTTPS protocol, and your server ...


5

There are lots of information about this topic on the internet and on this site, so it does not make sense to repeat everything: a short introduction on how this works you'll find at http://www.zdnet.com/article/how-the-nsa-and-your-boss-can-intercept-and-break-ssl/ and a discussion of the associated problems at What security risks are posed by software ...


3

This may be to avoid the use of this header to cause a denial of service attack. Imagine an insecure HTTP-only website. Now imagine someone able to tamper with the HTTP headers sent by this site to add an HSTS header. According to the RFC: The UA should stop trying to access the site through HTTP, and try to use HTTPS only instead. If the UA is unable to ...


3

Edit: I realise that this may not be clear from the answer below... but from the point of view of your application, it doesn't really make any difference whether you run the PKI/CA yourself or whether you use one or more third-party CAs. Even if you choose to run your own PKI, you really don't want to code it yourself - so you'd use one of the existing ones, ...


2

Actually, there is an often unused (at least on the web) optional part of SSL/TLS that allows for client authentication. It is generally not used on the web because the server doesn't really care if the client is who they say they are - they just need to have the proper credentials. Additionally, imagine the nightmare of having to verify every client in the ...


2

What I would say about the options that you outline is that HTTP Auth with SSL is a simpler but less flexible option and Oauth2 is more complex but has more flexibility in what you can achieve with it. One example, as you've noted in your ASCII art diagram, with OAuth2 it is possible to create a token which can be used in place of the password to ...


2

Your organization is most likely using a man-in-the-middle ssl cert. They have a program or proxy setup to authenticate your certificate as valid then submit another certificate to the website on your behalf. This is common for companies that must rely on pci or hipaa compliance. Unfortunately, when this is done then your passwords are exposed by this ...


2

You can not generate your own EV certificates and especially you can not generate self-signed EV certificates. Only some CA's are able to generate these and these CA's are specifically marked in the SSL stacks of the browser or operating systems. If you want to create EV by yourself you would have to change the SSL stack used by the browser to accept the ...


1

HPKP does not address this need. HPKP is an extension to the HTTP protocol allowing website administrators to provide specific pining information to the browser, allowing: To check that at least one of the certificate composing the authentication chain of the current HTTPS connection (depending on the platform architecture architecture, the server ...


1

If an OAuth 2.0 token is compromised, you only need to concern yourself for the TTL of the token. If an HTTP Basic Auth header is compromised, the credentials do not expire. You would manually need to change your client_id and secret, and that's if you even knew or thought they were compromised. And it's likely you would need to change your client code ...


1

I think this extension is quite simple and generally safe to use for two reasons: Firstly, on Q. When does HTTPS Everywhere protect me? When does it not protect me? section on HTTPS Everywhere website FAQ page HTTPS Everywhere depends entirely on the security features of the individual web sites that you use; it activates those security features, ...



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