I am not getting any SCTs when using OpenSSL. After setting up the SSL connection, I'm calling
SSL_enable_ct(ssl, SSL_CT_VALIDATION_PERMISSIVE);
const STACK_OF(SCT) *sct_stack = sk_SCT_new_null();
sct_stack = SSL_get0_peer_scts(ssl);
printf("%i SCTs obtained.\n", sk_SCT_num(sct_stack));
And it always prints out that I obtained 0 SCTs, regardless of the domain that I connect to. The thing is, the connection is being setup correctly, because I can grab the X509 certificate for any domain I connect to, and I can send OCSP requests and obtain responses to those requests. But when I try to grab the SCTs that should be sent, my code always informs me that there were no SCTs.
I have a strong feeling that it is my code that isn't working, because even when I connect to one of google's websites, such as google.com or gmail.com, I am unable to obtain any SCTs from the connection, despite the fact that Google pioneered certificate transparency.
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 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'm building a web service to allow salesforce to call to it, the two way SSL is used for security, and salesforce has provided its client certificate: sfdc-client.cert.
In order to test whether salesforce client certificate work or not, I have setup a very simple web on MAC apache and enable SSL and client authentication on ssl config file /etc/apache2/extra/httpd-ssl.conf as below (use self-signed):
SSLCertificateFile "/private/etc/apache2/ssl/server.crt"
SSLCertificateKeyFile "/private/etc/apache2/ssl/server.key"
SSLCACertificateFile "/private/etc/apache2/ssl/sfdc-client.cert"
SSLVerifyClient require
SSLVerifyDepth 10
The first browsing by Chrome, I got "SSL Connection Error", I supposed it's correct in this case.
Then, I have tried to import sfdc-client.cert to key chain access, but it does not work at all because it just supports p12/pfx format.
I also tried to use CURL:
curl https://test.com --cert-type der --cert sfdc-client.cert
but got the error:
curl: (58) unable to use client certificate (no key found or wrong pass phrase?)
I'm totally newbie on this stuff, does anyone know how to test client certificate to make sure it works as above?
First you need to have both the client's certificate and certificate private key to be able to test 2-way SSL authentication.
To test with web browser, follow instructions here: Is there a way to test 2 way ssl through browser?
I'm working on an embedded application (running MQX RTOS, written in C) which has SMTP functionality. Recently, TLS support was added using the Mocana NanoSSL library. I'm currently able to successfully send emails using Gmail, Yahoo, and private exchange servers. Unfortunately, Hotmail does not work. Here's the connection parameters i've used:
Server: smtp.live.com
Port: 25 and 587
AUTH method: PLAIN and LOGIN
Basically, i'm able to successfully connect to the server, perform the SSL/TLS handshake (using STARTTLS), and send the encrypted EHLO message to the server (receiving a response). According to this response, the server supports both AUTH PLAIN and AUTH LOGIN. However, once I send either of these commands, the following SSL_recv() call I make to get the response fails with either a timeout or connection reset by peer.
UPDATE:
OK, so after some experimentation it would appear that my issue lies at the SSL library level and not with Microsoft's SMTP server. I tried replacing the SSL_recv() calls with standard RTCS socket recv() calls and was able to receive and view encrypted data. By disabling my response verification, I was then able to continue through the SMTP process and successfully send a message. At this time i'm not sure why the SSL_recv() calls are unable to get the socket data, but i'll keep digging and will hopefully find an answer.
Well, I also got it working here too. I had to replace the
ssl_ctx=SSL_CTX_new(SSLv23_client_method());
with either:
ssl_ctx=SSL_CTX_new(SSLv3_client_method());
or
ssl_ctx=SSL_CTX_new(TLSv1_client_method());
My understanding is that the 23_client method sends a SSL2 client hello first and this confuses the server.
I read this in the HP SSL programming tutorial:
http://h71000.www7.hp.com/doc/83final/ba554_90007/ch04s03.html
it says: "However, the SSL client using the SSLv23 method cannot establish connection with the SSL server with the SSLv3/TLSv1 method because SSLv2 hello message is sent by the client."
SSL3 works too since you can continue after STARTTLS with SSL, you do not have to use TLS.
See here:
https://www.fastmail.fm/help/technology_ssl_vs_tls_starttls.html
So, it's the SSL library itself that appears to be failing me here. I was able to bypass the issue and successfully send email by simply not calling SSL_recv() to verify the server responses. I'm obviously not able to error check or get any meaningful failure feedback, but for a successful use case where the server accepts all of my SMTP messages the email is sent.
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.