Can a particular web page in a web site, authonticate a web request using client side SSL certificate, while others don't?
It's possible using SSL/TLS renegotiation. The way to configure it depends on the server you're using (and whether it supports it).
Note that, at the end of last year (October/November 2009), an SSL/TLS protocol flaw was discovered regarding this feature.
SSL/TLS stacks that support renegotiation based on code before that will be vulnerable to the attack. Most libraries did an emergency security update where they disable renegotiation altogether (therefore removing the client-certificate renegotiation). In February 2010, RFC 5746 was published with a fix to this problem, but not all stacks implement it yet.
I believe the most common way to secure a single page is to put it in a subfolder that is SSL-secured.
This article may help:
http://www.leastprivilege.com/PartiallySSLSecuredWebAppsWithASPNET.aspx
Related
Can a website check in the application layer which key/certificate the client is using?
Somehow detect that the certificate is not the real one, but issued by Sneakycorp Inc. because a man-in-the-middle attack is in progress.
I realize that the mitm could fake the response, but that raises the bar for simple copying proxies.
I see two possibilities:
Use code on client side
Use code on client side (e.g. JavaScript) to read the used certificate and send the info back to the server. Then on server side you could compare if the used certificate is the expected one.
It seems like in JavaScript it is not that easy to get the necessary info on the certificate. The used method in the linked answer seems to be Firefox only at the moment.
TLS fingerprinting
A second way is used by large content delivery sites: HTTPS fingerprinting
Based on the TLS headers you can generate a fingerprint on TLS stack and often also on the used technology/run-time and OS like .Net, Java, Python, and so on. If you then compare that with what you expect e.g. based on the user agent you can calculate the chance that you have a direct connection or if some man-in-the-middle server is active.
This is a very generic question and I hope I can get it right.
I am looking into SSL/TLS renegotiations and have read up a bit on it. Here's what I've understood from my reading:
Clients are grouped into two main groups from the standpoint of SSL/TLS renegotiations, patched and unpatched. This refers to if they're vulnerable to an Man In the Middle attack (CVE-2009-3555?) or not.
A renegotiation made with a patched client is called a "Secure renegotiation" while a renegotiation made with a unpatched client is called an "Insecure renegotiation".
The articles I have read has used a Web shop as an example where a user browsers the shop without being logged in. When the user decides to log in his/her client could then use renegotiation to login and save some time/resources.
What I don't understand from that example is why the browser would have to re-establish the SSL/TLS session when it already has one to the site? Unless the login is made over another domain, in which case I would have assumed that it would be a completely new session since the client can't assume that the same web server would handle that domain.
Most resources is very vague and I would like to understand from a practical standpoint:
In what scenario are they used?
What is the benefit?
What is the behavior of a client if they fail or are rejected?
Any answers/theories/suggestions would be appreciated.
/Patrik
They are used when either side wants to change the protocol or the cipher suite, or if the server now wants to request a client certificate and didn't before.
Is it possible to have a cut down implementation of TLS , where we just
presume the server we are connecting to is trusted - after the server sends its
certificate, can we bypass verification of this and do away with any further
processing , and get right into standard http ? Is using public key encryption
something that is absolutely necessary , or can it be skipped ?
Rewording my question.
Is it possible to write a tls engine by skipping the need to use RSA public key
code ?,
or
Can a client notify the server during the handshake that it just requires the severs certificate
info, company name, expiry dates and requests the secret cipher key to be sent in plain text.
Skipping something in a protocol I don't fully understand is generally a bad idea.
Only steps marked as optional in the RFC can be safely skipped.
Therefore if you don't plan to use client-side certificate based authentication you can skip it.
However what you can do however is limit the number of variations in your implementation. This means support only one TLS version (e.g. TLS 1.2) and support only one dedicated cipher suite.
Anyway the pitfalls when implementing TLS are so numerous that I recommend you to use an existing implementation (e.g. implementing in a way that does not allow side channel attacks is not that simple and requires knowledge on that topic). There are other implementations beside OpenSSL with a much smaller footprint.
BTW: If you can presume the connection is trusted you don't need TLS. If you need TLS it should be a secure.
where we just presume the server we are connecting to is trusted - after the server sends its certificate, can we bypass verification of this and do away with any further processing
The point of verification is less to find out if the server is trusted, but more that you are actually talking to the server you expect to. If you omit this step you are open to man-in-the-middle attacks.
But, TLS is a very flexible protocol and there are actually ways to use anonymous authentication or a shared secret with TLS and thus skip usage of certificates. Of course in this case you would need to have some other way to validate the server, because otherwise you would be still open to man-in-the-middle-attacks. And because this use case is mostly not relevant for the common usage on the internet it is usually not implemented inside the browsers.
We have a HTTP endpoint where a form request is posted containing transaction data from a 3rd party https website.
We are investigating ways that our HTTP endpoint can contain code to check that the host that posted the request is the 3rd party website and no-one else (i.e. a hacker).
Is there any way our HTTP endpoint can authenticate with the website where the posted form request originated? Maybe by SSL Certificate Authentication?
Many thanks in advance.
To guarantee that the server on the other side is who they say they are the safest way is to have them use an SSL Certificate. If the they also need to trust who you are then each side should have their own SSL Certificate.
The IP Range solution provided in the comment could be a possible hack but it's quite brittle and it couldn't be applied in a very serious environment.
The Shared Key solution will work and it's reliable but you have to change keys from time to time depending on the volume of traffic between the two servers.
Hope this helps.
It might be better to use message-level security instead of transport-level security (SSL/TLS).
The third party website would sign the message using its certificate (or to be precise, using the private key matching its certificate), and your website would verify this signature.
This could allow for that message to be relayed by the user's browser, without needing a direct connection between the two servers.
This sort of mechanism already exists in the Identity Management world, for example with SAML and Shibboleth. (You can still have direct connections between the servers to get additional information too.)
The ColdFusion documentation is weak on how and when to use it. What does it do? How does one use it?
Update: it seems to be broken, as outlined in Washing Client Certs in ColdFusion with SOAP – Part 2.
problems with CFHTTP handling SSLv3 sessions
Client certificates are a bit of a pain because of the overhead involved in using it.
As Jura says, you'll need a target server that uses client certificates as a mechanism for authentication. This server side piece does not need to be CF-based. The web server (IIS, for example) would be set up to require this. This is part of the SSL/TLS protocol, not specific to any language at the application level.
You would use this if the server you are requesting a resource from requires client certificates. The administrator of that server would need to give you the client certificate and private key ahead of time. As mentioned by user349433, this is commonly a PKCS12 (.p12 or .pfx) file.
The server will validate that the client certificate is "trusted" and if it is, it will allow the TLS/SSL handshake to proceed, and CF will be able to write the HTTP request on top of it.
The use case today is to prevent man-in-the-middle attacks, but because of the overhead involved with certificate distribution, revokation, etc. it's not terribly common.
If you want to know more about it, check out TLS 1.1 specification:
https://www.rfc-editor.org/rfc/rfc4346
https://www.rfc-editor.org/rfc/rfc4346#section-7.4.6
You are using client certificate in case if the target server uses that mechanism for authentication. You'll need to obtain specific client certificate from the service provider in order to be able to connect to the service. It's been used for some internet banking applications back in days I believe. Not sure what is the use case today for it, may be distributed corporate networks where you need to connect to corporate server over internet in a highly secure manner?