I am using faye for publishing and subscribing messages. Now i have to move my application over ssl. I am running my application https://localhost:44477 and my faye server runs as https://<ip>:9292. And i have to use self signed certificate for my application. I generated one self signed certificate and for using this, I add exception for my rails application when pop-up for untrusted connection comes on browser.
Problem occurs on accessing faye. Since i am calling faye from layouts as https://<ip>:9292/faye.js, browser needs to add exception for this url separately. But, since this I am accessing from layout, no separate pop-up comes for this, and it fails silently, till i open this in another browser and add exception.
Is there any way to handle adding exceptions for requests from backend/layouts?
Related
When a user tries to browse webpage having an invalid certificate(expired,self-signed, untrusted root, etc..),
browser warns the user about the security issue with page give option to proceed or return back.
Is it possible the change the page(default) that's being displayed here? how to get into the chain of event that gets trigger after the browser evaluates certificate validity?
Any help would be appreciated.
thanks,
It is impossible to achieve that feature on the server-side. It is a part of the client-side's browser implementation on validating the server-side’s certificate.
As you know, the Https connection based on the SSL/TLS version between the client-side and the server-side. establishing the TLS connection requires a handshake between the server-side and the client-side.
The client and server will provide the available TLS version during the process, including the supported certificate encryption algorithm and certificate public key. If the process fails, we cannot program the webpage displayed on the client-side since the TLS connection has not been established yet.
Feel free to let me know if there is anything I can help with.
I have a certificate for a domain example.com. So, every request in my application (MVC 3) is being redirected to the https://example.com. But the problem is, I can see the padlock icon in the Firefox browser
but one second later it disappears and I see that there is no certificate ?
I have no clue what's going on, can somebody enlighten me ? The application is being hosted on Windows Server 2008 R2.
The "...which is run by (unknown)" message is just a message telling you that the certificate only verifies the web site name, not the owner. The message is not very clear and has been reported as a bug to Mozilla.
The "Your connection to this site is only partially encrypted" message means that you're fetching at least some HTTP data as a part of your HTTPS page (check your font/image/media links on the page) and the data fetched via HTTP is not secure. A secure page should only link to HTTPS content, or someone listening to the connection may be able to the insecure communication and figure out what is done over the secure link. For example, if your cookies are not set as secure, they'll be sent over clear text too when fetching data from your site.
All in all, the SSL cert seems to be installed ok, but your page needs some updates to only link to secure content.
In my cross-platform app, I use QNetworkAccessManager to send HTTP requests to my HTTP service that requires authentication. I recently upgraded to QT5, and to my complete surprise on MacOSX my app would send a massive amount of requests to the my service as fast as possible in some scenarios.
After doing some debugging, it turns out that this would only happen when I specify bad auth credentials in my requests. QNetworkAccessManager would indefinitely resend requests to my service if invalid username/password were specified in my HTTP requests.
My code has worked for a long time in previous QT versions, so I decided it has to be something with QT5.
I stumbled upon a following enhancement that was added in QT5: https://bugreports.qt.io/browse/QTBUG-22033
Basically, the idea behind this enhancement os to check keychain for username/password if it intermediate proxy is requiring auth credentials. It turns out this was badly implemented, and this code has been added to the QNetworkAccessManager::authenticationRequired() signal, instead of being added to proxyAuthenticationRequired() signal.
The interesting part about this problem is that I don't set proxy for my application nor QNetworkAccessManager that I use. Which makes this problem so hard to debug!
Because of the bad placement, this "keychain querying" is happening with any authenticationRequired signal. The underlying getProxyAuth() method is calling "SecKeychainFindInternetPassword" with blank hostname which is matching a first "Internet Password" from my keychain and using it to send a request to my service with this new credentials. Imagine my surprise when I saw one of my other/personal passwords being sent to my HTTP service!
Not only this is a security issues, but it cause an infinite loop in your app. I opened a bug with QT about this: https://bugreports.qt.io/browse/QTBUG-30434
Is there a temporary solution? There is! I looked for a workaround to this issue for while. It is a nasty hack. But it works until QT guys get their ducks in a row. This hack works because it ensures that "SecKeychainFindInternetPassword" does not match any entries in the keychain, and therefore skipping that "keychain query".
Basically I am setting proxy hostname to " " instead of "" which will prevent any matching that causes an infite loop in my app.
Workaround:
QNetworkProxy proxy = manager_->proxy();
proxy.setHostName(" ");
manager_->setProxy(proxy);
I hope this is resolved in the next version of QT, so I can remove this horrible hack.
I have an application where the html/javascript code executes fine in a standalone browser safari, but when the ajax calls are executed in PhoneGap, they all fail with the Network Error 101.
I am requesting XML documents
Yes.
BUT, it does not gracefully handle certificate errors with the HTTPS protocol. I ended up writing my own code to establish the initial connection with the server and ignore the cert errors
here is the code
http://blog.clearlyinnovative.com/post/1012434483/phonegap-and-iphone-development
Phonegap does support HTTPS ajax requests, but like Aaron mention it does not gracefully handle certificate errors. In my case, we have valid certs in our production environment; but for our dev environment we overrode one of the NSUrl methods:
#implementation NSURLRequest (IgnoreSSL)
+ (BOOL)allowsAnyHTTPSCertificateForHost:(NSString *)host
{
return YES;
}
#end
This has been tested with phonegap 1.7(and 1.9) and it worked well. You can put this code in your MainViewController.m.
Note that I recommend this code only for development environment. This most likely will not be accepted by the app store; since we are overriding a private api. Just use valid certs in production.
I have an embedded web server with a self-signed SSL certificate. After I get past the Web Browser's warning about the SSL Certificate being self signed, I am seeing a difference between IE8 and Firefox 3.5.5.
In IE8, if I try to download a PNG file, it will download every time.
In FireFox, it will give me an error every other time.
The error message is this:
Secure Connection Failed
An error occurred during a connection to 192.168.1.100.
SSL peer was unable to negotiate an acceptable set of security parameters.
(Error code: ssl_error_handshake_failure_alert)
*The page you are trying to view can not be shown because the authenticity of the received data could not be verified.
*Please contact the web site owners to inform them of this problem. Alternatively, use the command found in the help menu to report this broken site.
What is causing this? Why does one browser work all the time and the other only works every other time?
It's hard to say without looking at the packets. If I had to hazard a guess, it would be that on the second request, Firefox is trying to resume the SSL session, and for some reason, the server doesn't like that. On the next request, Firefox doesn't try to resume, and it succeeds again. Maybe?