In an ASP.Net web app, which runs on HTTPS and has RequireClientCertificate set in web.config, I need to receive the client certificate of the user and digital signature of the request on the server. The certificate is found in HttpContext.Request.ClientCertificate, but I can't find the signed data. The post params are automatically decoded and decrypted, but I need the signature too. Does anyone know where is it found or is it possible to get it?
One more question, when the browser asks for your certificate and hands it to the server, does it encrypt the whole HttpRequest with your private key or just a part of it (for example post params)?
Thanks for any help
One more question, when the browser asks for your certificate and
hands it to the server, does it encrypt the whole HttpRequest with
your private key or just a part of it (for example post params)?
Firstly, it doesn't make sense to "encrypt with a private key": you sign with a private key. While some algorithms (e.g. RSA) use very similar procedures to encrypt and sign, "encrypt" means "hiding" something: you're not hiding anything if anyone with the public key can decipher it.
Secondly, SSL/TLS uses symmetric keys (negotiated during the handshake) for encryption, not the keys in the certificates. The whole HTTP request will indeed be encrypted in this case.
The certificate is found in HttpContext.Request.ClientCertificate, but
I can't find the signed data. The post params are automatically
decoded and decrypted, but I need the signature too. Does anyone know
where is it found or is it possible to get it?
What's signed when using a client certificate is the handshake messages, not the HTTP request. Once the appropriate verification has been made by your SSL/TLS stack, it's unlikely to be of any use, either technically or administratively. (This is why it is generally not accessible.)
Related
As a preface I'd like to claim I have some understanding of how the HTTP-supported authentication is supposed to work according to RFC 7235.
I am specifically interested to know how a client is supposed to know, after authenticating, which URIs on the server it is expected to provide same authorization (through the Authorization header) bearer for? Furthermore, is there any provision by HTTP to assist client in determining which Authorization headers it (the client) may have available (through whatever means it acquires them -- "login" form/dialog etc), would go with which realm(s)?
A realm doesn't seem to be specified in the form of an URI or even a regular expression of an URI, it's a value the interpretation of which appears to be left to the HTTP client application. Of note, a "Protection Space (Realm)" is defined, quoting:
A protection space is defined by the canonical root URI (the scheme and authority components of the effective request URI (see Section 5.5 of RFC7230) of the server being accessed, in combination with the realm value if present.
The above is all well and good, but it doesn't facilitate client mapping realms to URIs that may require authorization.
Say my Web server returns a response with status code 401 and the WWW-Authenticate: Bearer realm="The hangout" header line, for a request with a given URI, let's say /foobar. That makes it obvious that subsequent requests to the particular URI must include Authorization header line corresponding to solved challenge (as the client authenticates the user). No problem there. But what about e.g. requests with URI(s) that have the same pathname - those starting with /foobar/ -- is there an implication here that the same Authorization value is expected for these as well? What about entirely unrelated URI pathnames [on the same server]?
It would seem beneficial for the kind of authorization negotiation HTTP already does, to somehow relate or facilitate said relation of realms to URIs. But maybe I am missing something very obvious. Does HTTP do something along of what I am describing? Does it facilitate it in any way, at least, beyond leaving it entirely to the application? How would one realistically let the client determine which authorization bearer to send for which requests? Must it always get a 401 and a challenge response first, before knowing for sure requests to the particular URI and only said URI, must include related authorization bearer?
HTTP is a stateless protocol that deals with a request-response pair. The protocol does not deal with any information that would describe the concept of a "page", "site", "application", etc. Even though it deals with hypermedia, the protocol itself doesn't go beyond the concrete request. This means that you won't get any information from the protocol itself about any other paths under the same domain that are in the same authentication realm. This is left to the documentation of APIs or websites.
It seems to me that your research is centered on one type of authentication process that we call basic auth, know they are some other ways to authenticate a user and that they might suits your needs better as basic auth is kinda old as you can see on that RFC you linked.
To my understanding, the principle behind basic auth is to have a simple process based on challenges. When your client asks for a resource and that resource is protected by authentication, the server responds with a challenge : 401 Unauthorized with a header WWW-authenticate: Basic realm="some realm". The client then know the resource is restricted and depending on the realm, knows if it can have access (or asks the user for credentials for that realm), and try to access with a basic auth header : Authorization: Basic viFWGrwehryfviehtNRBRGWrwGERThRGE. You then repeat that process every time you need a resource.
HTTP and basic auth don't implement any sort of deeper and more complex system for authentication like you're searching for. It's one of the simplest system as its name implies and has not a lot more to offer. I'd even add that it's one of the riskier way to authenticate a system (even using SSL cert and cert pinning) as the client must send credentials for every single authenticated resource request.
In case you want to search other ways to authenticate requests, here are some :
OAuth (2.0) (most secured and complex)
Bearer (JWT or session tokens)
API keys
I am new to backend service and I was tracing API calls from a banking website. Normally, I have seen parameters in POST requests being encoded with base64 encoding. However, I came across a type of request where the date was encrypted with a type of encoding that I am unable to figure out.
For date: 19/12/2018 the encoding is: U2FsdGVkX1/o1qw9zIiZBHLAbGck6j15wwUZ/z/zLqw=
and for date: 18/12/2019 the encoded string is: U2FsdGVkX1/mo5+FfuqqqbUtCsdFObB8eKvyosc4b8E=
I am aware of only base64 encoding, but since I am unable to decode this with base64, it seems this is using something else. Appreciate if anyone can help and share some knowledge about the different ways in parameters can be sent to backend in a secret manner.
The encoding/encryption seems to be happening from the frontend side and I feel this could also be an encrypted string with seed sent in a separate parameter. Appreciate if someone can atleast share a list of possible algorithms that I can look into to understand the request sent and create my own requests.
we need to decide a mock-server for our applications. We have an ask in which the applications sends encrypted payload in request and response . that encryption is using rsa so the encrypted string changes for same payload so it is not possible to know by inspecting the encrypted string which request it is. and we should be able to inspect the payload and send the appropriate response. Have looked into the above three mockservers, I know mock-server has class callback mechanism through which i could decrypt the request and send but mock-server itself doesnt look that appealing. Anyone has any idea how can we mock encrypted request. ?
I'm implementing a REST API that also provides functionality for authenticating users. Authentication requires an user to send a POST request with the following data in the body:
{
"userOrEmail": "spook",
"passowrd": "Test1234"
}
If the username and password match, the user gets back a token from the server, while if they don't, the server returns 401 Unauthorized, with the following header:
WWW-Authenticate: Credentials realm="http://localhost:9000/auth/users/credentials"
Is that header acceptable? realm contains the location where the user can try to authenticate again.
It appears to be acceptable, but maybe not optimal except under very specific conditions. From RFC1945:
The realm value (case-sensitive), in combination with the canonical root URL of the server being accessed, defines the protection space. These realms allow the protected resources on a server to be partitioned into a set of protection spaces, each with its own authentication scheme and/or authorization database. The realm value is a string, generally assigned by the origin server, which may have additional semantics specific to the authentication scheme.
So, you can, but I might be paranoid about multiple applications using the same authentication and inadvertently cross-authenticating if they were to share the same realm name. Better would be to isolate the realm by application, just to be on the safe side.
No, it's not acceptable.
a) There is no authentication scheme called "credentials".
b) The purpose of the "realm" parameter is different.
I work on ASP.NET and was just reading this from the amazon directory http://docs.amazonwebservices.com/AmazonS3/latest/dev/RESTAuthentication.html where it states
Informally, we call this process "signing the request," and we call
the output of the HMAC algorithm the "signature" because it simulates
the security properties of a real signature. Finally, you add this
signature as a parameter of the request, using the syntax described in
this section.
When the system receives an authenticated request, it fetches the AWS
Secret Access Key that you claim to have, and uses it in the same way
to compute a "signature" for the message it received. It then compares
the signature it calculated against the signature presented by the
requester.
But i presume both the requests wont be same right. Request is signed (great!!) but HMAC of the response from the client browser is going to be different since it contains extra data Right? so how come requests can validate even though they are valid
You need to read the whole of the paragraphs you quoted from. Right before the piece you quoted it says:
To authenticate a request, you first concatenate selected elements of the request to form a string. You then use your AWS Secret Access Key to calculate the HMAC of that string.
So you calculate your HMAC from those selected elements, and when you submit the request, the server calculates an HMAC from those same elements, and then they are compared.