I need to make comparison (on the basis of time) on OCSP request/response between a mobile device and desktop clients. I understand that one can use OpenSSL and other similar command line tools to check OCSP on desktop clients. But I don’t know how to go about making OCSP request on a mobile phone.
I want to send OCSP request for known certificate (e.g Facebook's) to its OSCP URL (http://ocsp.digicert.com) and obtain the certificate's revocation status.
Is there any tool or a guide on sample code (preferably J2ME) that I can use to send OCSP request and get response?
I understand that the BouncyCastle library for mobile devices has some sample classes related to OCSP. I have gone through but I have not been able to make much sense from them.
You could base64 the OCSP request and send it across on HTTP to the OCSP URL and then time it. Note that there might be a CDN that would serve the OCSP Response and that would factor in with the latency as well by reducing it.
How do you create an OCSP Request:
http://unmitigatedrisk.com/?p=42
Related
From the request made in electron, I don't want the software like Fiddler to see how it should be done. Any help is very grateful
You can't. Such information is ultimately public (if the traffic is not encrypted by HTTPS, but Fiddler can also read this because it acts as a man in the middle), and there is even more sophisticated software, like Wireshark which lets you read any network traffic which is flowing through your LAN.
In case you are not using HTTPS: Use HTTPS with valid, non-self-signed certificates (like the free Let's Encrypt certificates) and enable certificate checking in Electron if you have it disabled (it's enabled by default) because Electron will then reject the self-signed certificate Fiddler uses for HTTPS traffic and thus will not make any request, which ultimately prevents Fiddler from reading them.
However, I would not bother about this issue at all. Anyone with access to the connection can sniff on it and even on HTTPS traffic if all secrets are accessible (i.e. the one sniffing sits on the same system or has access to it), so there really is no way to keep request/response information "secret" with some third party having access to all the secret stuff.
I'm using a 32-bit microcontroller (program code written in C) with very limited flash space that is communicating with a cellular module. I have an Azure account setup with an IoT Hub and I would like to send some device-to-cloud messages to my IoT Hub. I have tested and confirmed both HTTP and HTTPS communication to other servers. However, I can't find anywhere that specifies what the required HTTP headers are for sending a device-to-cloud message. Can anyone provide a description of the required HTTP message format (the HTTP start line, required HTTP headers and the HTTP header values)?
I found the Azure SDK for C, but even with all the optimization options turned on it takes up too much codespace for my microcontroller. I've tried following the code in the SDK for how the HTTP message is built, but I seem to be missing some pieces. I only have two or three device-to-cloud messages that I am sending, so I assume that if I know what the headers are it won't take much code to generate the device-to-cloud messages.
The cellular module I have is handling the X.509 certificates for mutual TLS authentication. Assume that is working. For this question I'm only concerned with finding the required HTTP message formatting for a Azure IoT device-to-cloud message.
EDIT:
Following a suggestion from a comment, I was eventually led to this page:
https://learn.microsoft.com/en-us/rest/api/iothub/device/senddeviceevent
Using the suggested HTTP POST (with my device specifics replaced), I am now getting a 401 error (IotHubUnauthorizedAccess). I thought I understood how the authentication was supposed to work, but I guess I was wrong.
My IoT device has a symmetric key. I thought I was supposed to include a header formatted as:
Authorization:SharedAccessKey=<my_primary_key>
but that doesn't work. My HTTP body is simply:
{"deviceID":<my_IoT_Device_ID>}
Where am I supposed to include the symmetric key information, and what is its format?
After some trial and error, we found out it's much easier than we thought. If you are using X.509 certificates for client authentication, you don't need to include anything in the HTTP message content to specify your authentication. The minimum required for an Azure device-to-cloud message using X.509 certificates for authentication is:
POST /devices/<id>/messages/events?api-version=2018-06-30 HTTP/1.1
Host:<fully-qualified-iothubname>.azure-devices.net
Content-Length:<number-of-bytes-in-the-JSON-body>
{"deviceID":"<id>",<your-JSON-formatted-custom-d2c-message-data>}
where <id> is the device ID as listed on the Azure IoT Hub and <fully-qualified-iothubname> is the IoT Hub name. I believe Azure supports chunked encoding if you want to do that instead of using the Content-Length header.
I'm having an issue with a web app I'm building. The web app consists of an angular 4 frontend and a dotnet core RESTful api backend. One of the requirements is that requests to the backend need to be authenticated using SSL mutual authentication; i.e., client certificates.
Currently I'm hosting both the frontend and the backend as Azure app services and they are on separate subdomains.
The backend is set up to require client certificates by following this guide which I believe is the only way to do it for Azure app services:
https://learn.microsoft.com/en-us/azure/app-service/app-service-web-configure-tls-mutual-auth
When the frontend makes requests to the backend, I set withCredentials to true — which, [according to the documentation][1], should also work with client certificates.
The XMLHttpRequest.withCredentials property is a Boolean that indicates whether or not cross-site Access-Control requests should be made using credentials such as cookies, authorization headers or TLS client certificates. Setting withCredentials has no effect on same-site requests.
Relevant code from the frontend:
const headers = new Headers({ 'Content-Type': 'application/json' });
const options = new RequestOptions({ headers, withCredentials: true });
let apiEndpoint = environment.secureApiEndpoint + '/api/transactions/stored-transactions/';
return this.authHttp.get(apiEndpoint, JSON.stringify(transactionSearchModel), options)
.map((response: Response) => {
return response.json();
})
.catch(this.handleErrorObservable);
On Chrome this works, when a request is made the browser prompts the user for a certificate and it gets included in the preflight request and everything works.
For all the other main browsers however this is not the case. Firefox, Edge and Safari all fail the preflight request because the server shuts the connection when they don't include a client certificate in the request.
Browsing directly to an api endpoint makes every browser prompt the user for a certificate, so I'm pretty sure this is explicitly relevant to how most browsers handle preflight requests with client certificates.
Am doing something wrong? Or are the other browsers doing the wrong thing by not prompting for a certificate when making requests?
I need to support other browsers than Chrome so I need to solve this somehow.
I've seen similar issues being solved by having the backend allow rather than require certificates. The only problem is that I haven't found a way to actually do that with Azure app services. It's either require or not require.
Does anyone have any suggestions on how I can move on?
See https://bugzilla.mozilla.org/show_bug.cgi?id=1019603 and my comment in the answer at CORS with client https certificates (I had forgotten I’d seen this same problem reported before…).
The gist of all that is, the cause of the difference you’re seeing is a bug in Chrome. I’ve filed a bug for it at https://bugs.chromium.org/p/chromium/issues/detail?id=775438.
The problem is that Chrome doesn’t follow the spec requirements on this, which mandate that the browser not send TLS client certificates in preflight requests; so Chrome instead does send your TLS client certificate in the preflight.
Firefox/Edge/Safari follow the spec requirements and don’t send the TLS client cert in the preflight.
Update: The Chrome screen capture added in an edit to the question shows an OPTIONS request for a GET request, and a subsequent GET request — not the POST request from your code. So perhaps the problem is that the server forbids POST requests.
The request shown in https://i.stack.imgur.com/GD8iG.png is a CORS preflight OPTIONS request the browser automatically sends on its own before trying the POST request in your code.
The Content-Type: application/json request header your code adds is what triggers the browser to make that preflight OPTIONS request.
It’s important to understand the browser never includes any credentials in that preflight OPTIONS request — so the server the request is being sent to must be configured to not require any credentials/authentication for OPTIONS requests to /api/transactions/own-transactions/.
However, from https://i.stack.imgur.com/GD8iG.png it appears that server is forbidding OPTIONS requests to that /api/transactions/own-transactions/. Maybe that’s because the request lacks the credentials the server expects or maybe it’s instead because the server is configured to forbid all OPTIONS requests, regardless.
So the result of that is, the browser concludes the preflight was unsuccessful, and so it stops right there and never moves on to trying the POST request from your code.
Given what’s shown in https://i.stack.imgur.com/GD8iG.png it’s hard to understand how this could actually be working as expected in Chrome — especially given that no browsers ever send credentials of any kind in the preflight requests, so any possible browsers differences in handling of credentials would make no difference as far as the preflight goes.
I am currently designing a web application using AngularJS. In this I am fetching and posting data via Rest API(s) with different methods. The data I retrieving is fetched in the form of JSON.
Problem:
Issue here is, while I am using https, the data sent and received via HTTP requests can still be seen in proxy tool or traffic monitors. All the JSON can be easily read from this.
Each of my request has a token attached in it's header which takes care of authentication. However, once authorized, there is some part I don't want to be displayed in/ caught in such monitoring tools.
Question:
This data is stored in an encrypted way in database and all, however while coming via HTTP request, it is first decrypted and then sent. How can I hide/protect this data?
You can't.
If you give it to the client, then the client has to be able to see it.
If the user has configured their browser to proxy requests, then the proxy is the client.
Once the data leaves your server in an HTTP response then anyone/anything thing the user of the client wants to trust with that data can access it. You don't have control at that point.
proxy tool or traffic monitors will see https data only if the client has accepted the man-in-the-middle (MITM) by installing the ssl certificate used by the MITM:
To see the content (other than the host name) of an https connection, someone who is neither the client or the server must do a MITM.
If someone do a MITM with a certificate not trusted by the client, the client will reject the connection.
WARNING: If the server do NOT use HSTS, the person doing the MITM can do an SSLSTRIP attack if the first connection is http. In that case, the MITM do not need a trusted certificate because the connection will stay in plain text (http)
I'd like to use the URL fetch service for app engine (java). I'm just sending a POST to one of my own servers from a servlet.
AppEngine -> post-to: https://www.myotherserver.com/scripts/log.php
I'm reading the url fetch doc:
Secure Connections and HTTPS
An app can fetch a URL with the HTTPS method to connect to secure servers. Request and response data are transmitted over the network in encrypted form.
The proxy the URL Fetch service uses cannot authenticate the host it is contacting. Because there is no certificate trust chain, the proxy accepts all certificates, including self-signed certificates. The proxy server cannot detect "man in the middle" attacks between App Engine and the remote host when using HTTPS.
I don't understand - the first paragraph makesit sound like everything that goes from the servlet on app engine, to my php script is going to be secure if I use https. The second paragraph makes it sound like the opposite, that it won't actually be secure. Which is it?
Thanks
There are two things HTTPS does for you. One is to encrypt your data so that as it travels over the internet, through various routers and switches, no one can peek at it. The second thing HTTPS does is authenticate that you are actually talking to a certain server. This is the part App Engine can't do. If you were trying to connect to www.myotherserver.com, it is possible that some bad guy named bob could intercept your connection, and pretend to be www.myotherserver.com. Everything you sent to bob would be encrypted on it's way to bob, but bob himself would be able to get the unencrypted data.
In your case, it sounds like you control both the sending server and the destination server, so you could encrypt your data with a shared secret to protect against this possibility.
The UrlFetch through https has been fixed allowing certificate server validation.
validate_certificate
A value of True instructs the application to send a request to the
server only if the certificate is
valid and signed by a trusted CA, and
also includes a hostname that matches
the certificate. A value of False
instructs the application to perform
no certificate validation. A value of
None defaults to the underlying
implementation of URL Fetch. The
underlying implementation currently
defaults to False, but will default to
True in the near future.