Thanks for the complement. Always nice to hear from a happy user. I like the 
extension too. I originally wrote it because I just wanted the functionality.

This is the issue that I've mentioned on the extension's description page in 
Google's extension gallery. It essentially happens because of a limitation in 
Chrome:
https://code.google.com/p/chromium/issues/detail?id=29314

I didn't have a bug in this bug tracker for it, so I guess this will serve as 
that.

Already voted and commented on the feature request.

How about making a development version of the plugin with this API 
https://code.google.com/chrome/extensions/dev/experimental.webNavigation.html

That looks like it's exactly what I need. Thanks! I'll try it out and update 
the progress here.

I am soo excited. Also, you might wanna check out 
https://chrome.google.com/extensions/detail/hllceldkphjbfpchpfmcgaeafheplfog I 
am currently checking it out to see if it does what we want.

It seems that the webNavigation API doesn't allow blocking/redirecting the 
request yet, only detecting it sooner:
https://code.google.com/p/chromium/issues/detail?id=50943#c22

I am starting to feel port to FF4 ftw.

Firefox definitely has more possibilities for extensions. But Chrome is getting 
there.

This feature seems to be planned for a future release, as mentioned in the 
bottom of this page:
http://dev.chromium.org/developers/design-documents/extensions/notifications-of-
web-request-and-navigation

Issue 36 has been merged into this issue.

Issue 37 has been merged into this issue.

This feature request on the ability to intercept HTTP request in Chrome is 
currently their most starred issue:
https://code.google.com/p/chromium/issues/detail?id=35897

Feel free to star it up to show interest.

If the site is white-listed, we should never be able to access to the HTTP site 
(only HTTPS), is that right ?

If this issue 25 become real, blacklisted should be disable,
indeed (like in issue 22 ) this will force the extension to detect if HTTPS 
access exist ?

If this issue is fixed, SSL should be enforced on whitelisted sites, without 
any unencrypted request. The only exception so far, is if the site has an 
infinite loop of redirecting to HTTP from SSL while the extension is 
redirecting the other way, then the extension will blacklist the site. Some 
sites (e.g. linkedin.com) has SSL, but redirects some pages like this.

Also certain sites (can't think of them now) have a https version just to tell 
you to use http HAHAHA. So, stupid sites like that you will want to blacklist 
otherwise you would get a cache 22.

As some of you might have noticed, issue 50943 in Chromium is fixed:
https://code.google.com/p/chromium/issues/detail?id=50943

But unfortunately this doesn't make it possible to fix this issue. It's still 
an experimental feature, which means it can't be used in extensions and it 
doesn't support altering the requests, which means we can't stop the insecure 
request from being sent. The only thing this gives us so far (when it comes out 
of experimental), is the ability to see the HTTP requests at an earlier stage. 
Which is getting closer, but it's not enough.

The Chromium issue 35897 addresses being able to block requests, which should 
mean that we could prevent insecure requests from happening and then reissue 
them as encrypted requests.
https://code.google.com/p/chromium/issues/detail?id=35897

So this is unfortunately still not possible.

Jsyk, You can tag this issue as "blocked on" the Chromium project issue by 
entering the issue id as chromium:35897

Great. Thanks.

Issue chromium:35897 has since been marked as a duplicate of issue 
chromium:60101, so the latter is the one this issue has been marked a duplicate 
of now.

Here's a heads up on the progress for this issue:
This is now implemented in the repository and it seems to work quite well. 
Unfortunately the WebRequest API that this feature requires is still set as an 
experimental feature in Chrome, so it can't be released for public consumption 
just yet. In issue chromium:60101 it seems to be set to version 17 of Chrome 
and we're currently on version 14 on the stable channel.

Please feel free to test it out and give feedback. We could probably package it 
up and create some installation instructions to make it easier, but essentially 
you need to start Chrome with the --enable-experimental-extension-apis 
parameter and then add the directory from the repository under extensions. 
Don't forget to disable the stable extension. They shouldn't conflict, but 
there's no reason to run both. You'll need to run Chrome with that parameter 
every time you want to use the unstable extension. And remember that the 
repository is where the development is occurring and you could see bugs and 
such (although hopefully not, of course).

So hang in there. This feature is coming as soon as possible.

Couldn't you replace all links to whitelisted domains on page load (so that all 
links from that site again will use https).

That already happens. The issue is that it can only happen after the page is 
already loaded over HTTP. With the new WebRequest API, this will change though. 
As mentioned in comment 21, the code is in the repository for utilizing this 
and it works great so far. It'll also get rid of the need for changing the 
links on the pages, since all requests will be fixed before they are sent. As 
soon as the WebRequest API is released as a non-experimental API, this will 
make it into the official released extension.

FWIW, 17 is in the dev channel now; is the change here in the mainline 
extension or still only in the unstable repo?

The webRequest API still seems to be in experimental status even in 17. It 
can't be in the mainline extension until that changes.

The unstable repo does implement the feature, but there is a known issue with a 
very long timeout on the HTTPS requests. And the handling of HTTP(S) requests 
has had some issues, that means it could be changed soon: issue chromium:105656.

Google says webrequest api is no longer experimental:
http://code.google.com/chrome/extensions/trunk/experimental.webRequest.html

I don't know since when, but as chromium 17 is their current stable release, I 
guess it's in there.

I uninstalled the official extension and installed the beta in Chrome Canary 
(19.0.1054.0) and everything seems to be working fine.  Opening the "Options" 
page the first time immediately after install caused a crash, but it hasn't 
happened again since.  It might have not been done installing or it might have 
been a memory issue.  I'll report back if it happens again.  SSL-wise, it works 
for me exactly as you stated.  First request goes to non-SSL page, then 
subsequent requests go immediately to SSL version with no redirect.  Is there a 
reason you decided not to do the "redirect after load" method for  the first 
request?  Better user experience with no reloading?

Great. Thanks for the feedback.

My reasoning was that the request has already happened and it can't currently 
be held back while the extension checks for SSL. So we might as well just let 
it go and then only redirect when we've done the check. It does visually seem 
like it's not working right away, so there might need to be some warning 
explaining this somewhere to avoid confusion.

I didn't experience any crashes, so let's hope that's just some mistake in the 
developer version of Chrome you're running and then obviously keep an eye on if 
it happens again.

Let me know if you have it running for a while and how that goes. Just in case 
there are any issues on some obscure site or something.

The beta version seems to cache the domains in incognito mode. Be aware of 
that. I'll look into the issue.

FYI, this version seems to break http://www.groupon.com.  After the first page 
load, subsequent requests all return "This webpage has a redirect loop" (Error 
310 (net::ERR_TOO_MANY_REDIRECTS): There were too many redirects.)  
Blacklisting the page DOES NOT fix the issue, but pausing KB allows the page to 
load like normal.  Maybe it needs a redirect counter, so that if the SSL page 
redirects back to the non-SSL page, it stops trying to redirect the the SSL 
version?  This the the first page I've experienced this on, though.  Thanks for 
the great work.

@35: I can see this is an issue with the detection of domains with and without 
www. You can get it working for now by disabling this feature.

I can confirm that this fixes the issue at least for Groupon.com.  I had it 
come up on some other sites, so I'll tell you if any other sites have a problem 
after disabling this option.  Thanks for the quick feedback.

Here's a weird one.  Going to this URL: http://wireddeals.com/post/1886866 
redirects me to https://www.google.com/.  Pausing KB SSL Enforcer causes the 
correct page to load: 
http://www.fatwallet.com/forums/hot-deals/1173191/?utm_source=feedburner&utm_med
ium=feed&utm_campaign=Feed%3A+FatwalletHotDeals+%28Fatwallet.com+Hot+Deals%29.  
Can anyone recreate this?

Just tried Curl on that URL, got this:

$ curl http://wireddeals.com/post/1886866
<html><head><meta http-equiv="refresh" 
content="0;url=http://feedproxy.google.com/~r/FatwalletHotDeals/~3/iFNJv-quJEk/"
/></head></html>

Curl on that new URL gives me:

$ curl http://feedproxy.google.com/~r/FatwalletHotDeals/~3/iFNJv-quJEk/
<HTML>
<HEAD>
<TITLE>Moved Permanently</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
<H1>Moved Permanently</H1>
The document has moved <A HREF="http://www.fatwallet.com/forums/hot-deals/117319
1/?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+FatwalletHotDeals+
%28Fatwallet.com+Hot+Deals%29">here</A>.
</BODY>
</HTML>

But if I try https instead:

$ curl https://feedproxy.google.com/~r/FatwalletHotDeals/~3/iFNJv-quJEk/
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">
<TITLE>302 Moved</TITLE></HEAD><BODY>
<H1>302 Moved</H1>
The document has moved
<A HREF="http://www.google.com">here</A>.
</BODY></HTML>

So it's not a KB SSL enforcer issue, rather Google has its redirects broken for 
the domain feedproxy.google.com.

@Comment 39

Google does that for all domains requested with SSL that don't support SSL. The 
domain feedproxy.google.com should be excluded from kbsslenforcer

@38-40: Yes, it's https://feedproxy.google.com that's redirecting to 
google.com. Google has been opening up for SSL on more and more of their 
services lately, so we can only hope they will enable it for 
feedproxy.google.com as well. But until then, you can at least blacklist the 
domain.

I just added a feature suggestion relating to Google's SSL redirection scheme, 
in a more generic form, in issue 79.

Issue 80 has been merged into this issue.

The issue with infinite redirects on groupon.com and other sites when the "with 
and without www" feature was enabled, should now be fixed in the repository. 
I'll release another beta soon. But feel free to grab it from the repository if 
you're adventurous. The incognito issue is still not fixed.

Hi, I've tried the SVN version. I found an issue: if you type any word in the 
omnibar and press ENTER, it adds it to the blacklist.

Eg: I type foobar in the omnibox, and then press enter; the browser sends me to 
Google to do the search for "foobar". I go to the KB SSL option screen, open 
the blacklist, and it contains "foobar".

I don't know if it's related, but I have two experimental features in 
chrome://flags: preload instant search and omnibox prerendering. 

Another issue is that there's a conflict with AdBlock: in fact, AdBlock uses 
the webRequest API to block requests to URL containing advertisements (matching 
regexps); if KB SSL modifies the same request to redirect to HTTPS, a conflict 
happens.

The webRequest API doc says. "If an extension cancels a request, all extensions 
are notified by an onErrorOccurred event. Only one extension is allowed to 
redirect a request or modify a header at a time. If more than one extension 
attempts to modify the request, the most recently installed extension wins and 
all others are ignored."

The browser notifies me of the conflict and says that an extension (AdBlock) 
was trying to modify a request while another extension has already modified it 
(KB SSL). The order is just causal: I just happen to have installer KB SSL 
later than AdBlock.

I can't find a reproduction recipe for this bug. The AdBlock extension I'm 
using is this one:
https://chrome.google.com/webstore/detail/cfhdojbkjhnklbpkdaibdccddilifddb

what's the latest with this?

The extension hasn't seen the development time lately that it deserves. It will 
happen though. Sorry for the delay in this. Help is obviously appreciated if 
you have coding experience.

Has any further progress been made in the development of the extension?

FYI you can use Chrome's HSTS support to blacklist certain domains that should 
always use HTTPS:

chrome://net-internals/#hsts

Here's a new beta, version 1.5.2. Here are the updates:

* The infinite loop issue should be fixed, by detecting if the secure, 
authenticated SSL response redirects to the same domain unencrypted and putting 
it on the ignore list for not supporting SSL fully
* The whitelist and blacklist are now called enforced and ignored for clarity
* It still doesn't respect incognito mode properly, yet
* The first request to a new site is still not redirected, cause chrome doesn't 
allow synchronous xmlhttprequests to block a request (this might not be 
possible to fix as long as that limitation is in place, but it does redirect 
all unencrypted requests before they leave the browser from then on including 
after browser restart and all)

Feedback is welcome. And sorry for the long wait.

Btw, the enforced and ignored wording is to solve issue 31.

To respond to comment 50: There doesn't seem to be an API for extensions to 
manipulate the HSTS list. And the new version will achieve the same result.

Here's another beta, version 1.5.3. It fixes the incognito issue and some other 
minor bugs. I'm not aware of any release-hindering issues, so given enough 
testing without any new issues showing up, this will be the version released.

There was a minor issue, where the options page didn't respect the setting for 
checking both domains with and without www. This is now fixed in this beta, 
version 1.5.4.

This issue is now fixed with version 2.0, which has just been released. Sorry 
for the long delay. But hey, it's out, it's free and it's better now. :)

I'll set this issue as fixed. If there are any problems with the new version, 
please report a new issue.