Yes, the SSL connection is between the TCP layer and the HTTP layer. The client and server first establish a secure encrypted TCP connection (via the SSL/TLS protocol) and then the client will send the HTTP request (GET, POST, DELETE…) over that encrypted TCP connection.
Yes, it is. But using GET for sensitive data is a bad idea for several reasons: Mostly HTTP referrer leakage (an external image in the target page might leak the password[1]) Password will be stored in server logs (which is obviously bad) History caches in browsers Therefore, even though Querystring is secured it’s not recommended … Read more
The problem appears when your server has self signed certificate. To workaround it you can add this certificate to the list of trusted certificates of your JVM. In this article author describes how to fetch the certificate from your browser and add it to cacerts file of your JVM. You can either edit JAVA_HOME/jre/lib/security/cacerts file … Read more
There is a supported API for accomplishing this! Add something like this to your NSURLConnection delegate: – (BOOL)connection:(NSURLConnection *)connection canAuthenticateAgainstProtectionSpace:(NSURLProtectionSpace *)protectionSpace { return [protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]; } – (void)connection:(NSURLConnection *)connection didReceiveAuthenticationChallenge:(NSURLAuthenticationChallenge *)challenge { if ([challenge.protectionSpace.authenticationMethod isEqualToString:NSURLAuthenticationMethodServerTrust]) if ([trustedHosts containsObject:challenge.protectionSpace.host]) [challenge.sender useCredential:[NSURLCredential credentialForTrust:challenge.protectionSpace.serverTrust] forAuthenticationChallenge:challenge]; [challenge.sender continueWithoutCredentialForAuthenticationChallenge:challenge]; } Note that connection:didReceiveAuthenticationChallenge: can send its message to challenge.sender (much) … Read more
I tested it thoroughly before publishing. Of all the browsers available to test against on Browsershots, I could only find one that did not handle the protocol relative URL correctly: an obscure *nix browser called Dillo. There are two drawbacks I’ve received feedback about: Protocol-less URLs may not work as expected when you “open” a … Read more
To allow https wrapper: the php_openssl extension must exist and be enabled allow_url_fopen must be set to on In the php.ini file you should add this lines if not exists: extension=php_openssl.dll allow_url_fopen = On
The Apache docs recommend against using a rewrite: To redirect http URLs to https, do the following: <VirtualHost *:80> ServerName www.example.com Redirect / https://www.example.com/ </VirtualHost> <VirtualHost *:443> ServerName www.example.com # … SSL configuration goes here </VirtualHost> This snippet should go into main server configuration file, not into .htaccess as asked in the question. This article … Read more
You have basically two options here: add the self-signed certificate to your JVM truststore or configure your client to Option 1 Export the certificate from your browser and import it in your JVM truststore (to establish a chain of trust): <JAVA_HOME>\bin\keytool -import -v -trustcacerts -alias server-alias -file server.cer -keystore cacerts.jks -keypass changeit -storepass changeit Option … Read more
A relative URL without a scheme (http: or https:) is valid, per RFC 3986: “Uniform Resource Identifier (URI): Generic Syntax”, Section 4.2. If a client chokes on it, then it’s the client’s fault because they’re not complying with the URI syntax specified in the RFC. Your example is valid and should work. I’ve used that … Read more
To first force HTTPS, you must check the correct environment variable %{HTTPS} off, but your rule above then prepends the www. Since you have a second rule to enforce www., don’t use it in the first rule. RewriteEngine On RewriteCond %{HTTPS} off # First rewrite to HTTPS: # Don’t put www. here. If it is … Read more