Onderwerp: MS to stop allowing passwords in URLs

I just read that Microsoft will stop allowing IDs and passwords to be
embedded in URLs used by Internet Explorer. So you will no longer be
able to use a URL like https://userassword@www.somehost.com/

See http://support.microsoft.com/default...b;en-us;834489

Their reasoning is that this will mitigate status bar spoofing as has
recently been discussed here and in other forums. The article even goes
so far as to admit that recent versions of IE show only the URL before
the @ sign while older versions do not.

Apparently MS has decided that this RFC URL syntax is simply too
dangerous to allow in their products.=20

Their suggested workarounds include among others:
1) Having users click the "Remember my password" checkbox in IE.
2) Using cookies.

I personally use this syntax in only one production application, BBTray
- a windows tray applet that watches my bigbrother monitoring server.
Click the applet and it opens a browser window with the
idassowrd@server.com syntax. The ID and password is specific to our
bigbrother application, my workstation sits behind two firewalls and I
am the only admin on the box. So, I consider this use to be legit and
relatively safe given the convenience it provides.

I certainly don't consider the "remember my password" functionality nor
stored cookies any more or less safe than this syntax.

Anyone have any comments regarding legitimate uses of this syntax and
Microsoft removing it from their browser? (and presumably the OS since
the browser IS the OS).

Andrew McAllister
University of Missouri

Interestingly, I've already found that this patch doesn't fix this problem
when using IE as an object in VB6. You can still programmatically call an
instance of IE as a browser object and use that format to login to a web site.

At 05:54 PM 1/28/2004, McAllister, Andrew wrote:
>I just read that Microsoft will stop allowing IDs and passwords to be
>embedded in URLs used by Internet Explorer. So you will no longer be
>able to use a URL like https://userassword@www.somehost.com/
>
>See http://support.microsoft.com/default...b;en-us;834489
>
>Their reasoning is that this will mitigate status bar spoofing as has
>recently been discussed here and in other forums. The article even goes
>so far as to admit that recent versions of IE show only the URL before
>the @ sign while older versions do not.
>
>Apparently MS has decided that this RFC URL syntax is simply too
>dangerous to allow in their products.
>
>Their suggested workarounds include among others:
> 1) Having users click the "Remember my password" checkbox in IE.
> 2) Using cookies.
>
>I personally use this syntax in only one production application, BBTray
>- a windows tray applet that watches my bigbrother monitoring server.
>Click the applet and it opens a browser window with the
>idassowrd@server.com syntax. The ID and password is specific to our
>bigbrother application, my workstation sits behind two firewalls and I
>am the only admin on the box. So, I consider this use to be legit and
>relatively safe given the convenience it provides.
>
>I certainly don't consider the "remember my password" functionality nor
>stored cookies any more or less safe than this syntax.
>
>Anyone have any comments regarding legitimate uses of this syntax and
>Microsoft removing it from their browser? (and presumably the OS since
>the browser IS the OS).
>
>Andrew McAllister
>University of Missouri


Vinny Abello
Network Engineer
Server Management
vinny@tellurian.com
(973)300-9211 x 125
(973)940-6125 (Direct)
PGP Key Fingerprint: 3BC5 9A48 FC78 03D3 82E0 E935 5325 FBCB 0100 977A

Tellurian Networks - The Ultimate Internet Connection
http://www.tellurian.com (888)TELLURIAN

There are 10 kinds of people in the world. Those who understand binary and
those that don't.

Andrew - I agree entirely about "Remember my password" and cookies being
no safer. Password saving on shared machines is a nightmare - especially
as machines built with XP by default allow you to have a passwordless
generic login to the machine.

Seeing some of the passwords that come up on machines in cafes etc makes
me understand why there is so much shared-machine related fraud and
misuse of people's webmail accounts.

Also I have found that often to get to an FTP server on the Internet
(depending on the proxy, connection, firewall etc) that you need to use
this format. Taking this functionality away will certainly make it
harder for a lot of support people and consultants to do their jobs.

Back to having *every imaginable tool* in the CD case when visiting
client sites. Or maybe we should just starting putting all our good
stuff up on anonymous FTP sites?

Rgds...


-----Original Message-----
From: McAllister, Andrew [mailto:McAllisterA@umsystem.edu]
Sent: Thursday, 29 January 2004 6:54 AM
To: bugtraq@securityfocus.com
Subject: MS to stop allowing passwords in URLs


I just read that Microsoft will stop allowing IDs and passwords to be
embedded in URLs used by Internet Explorer. So you will no longer be
able to use a URL like https://userassword@www.somehost.com/

See http://support.microsoft.com/default...b;en-us;834489

Their reasoning is that this will mitigate status bar spoofing as has
recently been discussed here and in other forums. The article even goes
so far as to admit that recent versions of IE show only the URL before
the @ sign while older versions do not.

Apparently MS has decided that this RFC URL syntax is simply too
dangerous to allow in their products.

Their suggested workarounds include among others:
1) Having users click the "Remember my password" checkbox in IE.
2) Using cookies.

I personally use this syntax in only one production application, BBTray
- a windows tray applet that watches my bigbrother monitoring server.
Click the applet and it opens a browser window with the
idassowrd@server.com syntax. The ID and password is specific to our
bigbrother application, my workstation sits behind two firewalls and I
am the only admin on the box. So, I consider this use to be legit and
relatively safe given the convenience it provides.

I certainly don't consider the "remember my password" functionality nor
stored cookies any more or less safe than this syntax.

Anyone have any comments regarding legitimate uses of this syntax and
Microsoft removing it from their browser? (and presumably the OS since
the browser IS the OS).

Andrew McAllister
University of Missouri
--
This message has been scanned by AVMail

McAllister, Andrew wrote:
> I just read that Microsoft will stop allowing IDs and passwords to be
> embedded in URLs used by Internet Explorer. So you will no longer be
> able to use a URL like https://userassword@www.somehost.com/
>
> See http://support.microsoft.com/default...b;en-us;834489
>
> Their reasoning is that this will mitigate status bar spoofing as has
> recently been discussed here and in other forums. The article even goes
> so far as to admit that recent versions of IE show only the URL before
> the @ sign while older versions do not.
>
> Apparently MS has decided that this RFC URL syntax is simply too
> dangerous to allow in their products.
>
> Their suggested workarounds include among others:
> 1) Having users click the "Remember my password" checkbox in IE.
> 2) Using cookies.
>
> I personally use this syntax in only one production application, BBTray
> - a windows tray applet that watches my bigbrother monitoring server.
> Click the applet and it opens a browser window with the
> idassowrd@server.com syntax. The ID and password is specific to our
> bigbrother application, my workstation sits behind two firewalls and I
> am the only admin on the box. So, I consider this use to be legit and
> relatively safe given the convenience it provides.
>
> I certainly don't consider the "remember my password" functionality nor
> stored cookies any more or less safe than this syntax.
>
> Anyone have any comments regarding legitimate uses of this syntax and
> Microsoft removing it from their browser? (and presumably the OS since
> the browser IS the OS).
>
> Andrew McAllister
> University of Missouri
>

Despite what MS's notice says, presumably the primary motive for this
was to avoid the URL spoofing detailed here
(http://www.microsoft.com/technet/tre...n/MS04-004.asp).
In fact, that webpage specifically states that it is to fix ``three
newly-discovered vulnerabilities'' (``newly=discovered'' apparently
being a relative term), including ``a misrepresentation of the URL in
the address bar of an Internet Explorer window''.

So the security reasons they cite on the page you link to probably
aren't that they consider that syntax to be insecure relative to cookies
or ``Remember My Password'', but that the best way to avoid URL spoofing
they could come up with (after, apparently, months of effort) was to
eliminate the feature alltogether.

I can think of another great way to fix the vulnerabilities in Windows.
It's called fdisk.

Hope that helps!

Vinny Abello [mailto:vinny@tellurian.com] wrote...
> Interestingly, I've already found that this patch doesn't fix
> this problem when using IE as an object in VB6.

From the KB article:
http://support.microsoft.com/default...b;en-us;834489
"After you install the 832894 security update, you can set registry values
to use this new behavior in other programs that host the Web browser control
or to disable this new behavior for Windows Explorer and Internet Explorer."

The specifics of the registry values are also documented therein.

-FF

RFC 1738 (http://www.ietf.org/rfc/rfc1738.txt) states is section 3.3
(Note the last sentence):

-------------------
-- begin excerpt --
-------------------
An HTTP URL takes the form:

http://<host>:<port>/<path>?<searchpart>

where <host> and <port> are as described in Section 3.1. If :<port>
is omitted, the port defaults to 80. No user name or password is
allowed.
-----------------
-- end excerpt --
-----------------

So Microsoft has finally just adopted the RFC standard, not broken it.

Anyway, you can always re-enable the old system, as documented in the
Microsoft document you link, viz:

-------------------
-- begin excerpt --
-------------------
How to disable the new default behavior for handling user information in
HTTP or HTTPS URLs
To disable the new default behavior in Windows Explorer and Internet
Explorer, create iexplore.exe and explorer.exe DWORD values in one of
the following registry keys and set their value data to 0:

For all users:
HKEY_LOCAL_MACHINE\Software\Microsoft\Internet
Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME _PASSWORD_DISABLE

For the current user only:

HKEY_CURRENT_USER\Software\Microsoft\Internet
Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME _PASSWORD_DISABLE
-------------------
-- end excerpt --
-------------------

The other options are more secure in some ways, most specifically if the
address is visible anywhere on screen, there is no reference to the
username/password for anyone who passes by. I have this problem with our
help desk at work - they have a PC which has the username/password of
our network monitoring system visible in the URL, which any client who
visits can see. Which is one reason why I will only give them read
access :-)

Further, the other options (at least yet) have no ways of breaking them
that will hide the real URL you are visiting, since they only handle the
username/password, and have no linkage to the actual web address.

That's my 2c anyway.

--
Andrew Harwood
aaharwood@bigpond.com

-----Original Message-----
From: McAllister, Andrew [mailto:McAllisterA@umsystem.edu]
Sent: Thursday, 29 January 2004 09:24
To: bugtraq@securityfocus.com
Subject: MS to stop allowing passwords in URLs


I just read that Microsoft will stop allowing IDs and passwords to be
embedded in URLs used by Internet Explorer. So you will no longer be
able to use a URL like https://userassword@www.somehost.com/

See http://support.microsoft.com/default...b;en-us;834489

Their reasoning is that this will mitigate status bar spoofing as has
recently been discussed here and in other forums. The article even goes
so far as to admit that recent versions of IE show only the URL before
the @ sign while older versions do not.

Apparently MS has decided that this RFC URL syntax is simply too
dangerous to allow in their products.

Their suggested workarounds include among others:
1) Having users click the "Remember my password" checkbox in IE.
2) Using cookies.

I personally use this syntax in only one production application, BBTray
- a windows tray applet that watches my bigbrother monitoring server.
Click the applet and it opens a browser window with the
idassowrd@server.com syntax. The ID and password is specific to our
bigbrother application, my workstation sits behind two firewalls and I
am the only admin on the box. So, I consider this use to be legit and
relatively safe given the convenience it provides.

I certainly don't consider the "remember my password" functionality nor
stored cookies any more or less safe than this syntax.

Anyone have any comments regarding legitimate uses of this syntax and
Microsoft removing it from their browser? (and presumably the OS since
the browser IS the OS).

Andrew McAllister
University of Missouri

On 2004-01-28 McAllister, Andrew wrote:

[ MS about to invalidate usage of http://<user>:<pass>@<host> in IE ]

> Anyone have any comments regarding legitimate uses of this syntax and
> Microsoft removing it from their browser? (and presumably the OS since
> the browser IS the OS).

There is no legitimate use of this syntax and never was. Although
RFC 2396 does specify a generic URI syntax allowing

<user>:<pass>@<host>:<port>

it expressly excludes those URLs whose syntax is specified in RFC 1738:

| This document updates and merges "Uniform Resource Locators" [RFC1738]
| and "Relative Uniform Resource Locators" [RFC1808] in order to define
| a single, generic syntax for all URI. It excludes those portions of
| RFC 1738 that defined the specific syntax of individual URL schemes;
| those portions will be updated as separate documents, as will the
| process for registration of new URI schemes.

RFC 1738 clearly says:

| An HTTP URL takes the form:
|
| http://<host>:<port>/<path>?<searchpart>

So do RFCs 1945 and 2616.

Regards
Ansgar Wiechers

Dear McAllister, Andrew,


--Thursday, January 29, 2004, 1:54:00 AM, you wrote to bugtraq@securityfocus.com:



MA> Anyone have any comments regarding legitimate uses of this syntax and
MA> Microsoft removing it from their browser? (and presumably the OS since
MA> the browser IS the OS).

ftp://userass@site

is _only_ way to authenticate FTP through HTTP proxy (if not given,
proxy always use anonymous).

--
~/ZARAZA
Âñåãäà áóäåì ðàäû ïîñëóøàòü âàøå ÷èðèêàíüå (Òâåí)

Andrew,

You said:
<I just read that Microsoft will stop allowing IDs and passwords to be
<embedded in URLs used by Internet Explorer. So you will no longer be
<able to use a URL like https://userassword@www.somehost.com/

I wanted to point out the option to make a reg key change that will
maintain the user@ functionality instead of utilizing the new default
behavior that occurs by applying the patch.

<snipped from MS article>
How to disable the new default behavior for handling user information in
HTTP or HTTPS URLs To disable the new default behavior in Windows Explorer
and Internet Explorer, create iexplore.exe and explorer.exe DWORD values
in one of the following registry keys and set their value data to 0:

For all users:
HKEY_LOCAL_MACHINE\Software\Microsoft\Internet
Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME _PASSWORD_DISABLE

For the current user only:

HKEY_CURRENT_USER\Software\Microsoft\Internet
Explorer\Main\FeatureControl\FEATURE_HTTP_USERNAME _PASSWORD_DISABLE


Overall, I think that MS is doing the right thing with this. I cannot
count how many html email's I've received that are supposedly from PayPal,
or Visa or <insert your favorite finacial organization here> wherein a
kiddie wannabe with minimal english skills asks "please verafy your
accoont information". That information is piped to a cgi on a hacked box
somewhere that snarfs the info then redirects you to the real site that is
supposedly asking for the info.

*yawn*

I guarantee that there are people out there (although probably not on this
list) that have swallowed the bait and forwarded their credit card #, SSN
#, all their pin numbers to every bank account they own as well as their
grandmothers bra size because they were presented with an official looking
html email that asked for the info. Why else do so many of these types of
con jobs flood the net?

This is getting to be as bad as the Nigerian email scam. You know the one
that starts out, "Dear Sir, <insert impressive title of some 3rd world
country here> left me 10 million dollars and I need your help."

Overall I think it's the right thing to do and I'm glad that MS is doing
it.

just my .02 so please, flames > /dev/null

Regards,

Dave McCormick
dave@fred.net_nospam.com
mccormic@xecu.net_nospam.com

"Kool-Aid anyone?" - Bill Gates

This has already been implemented in the out-of-schedule IE patch they
released yesterday, MS04-040. This is also the first time they broke their
promised monthly patch schedule, so far they have released patches in the
second week of the month.

http://www.microsoft.com/technet/sec...n/MS04-004.asp

Navigating to a link with Basic Authentication details embedded
(userassword@host) now yields an "invalid syntax error". Embedding HTTP
authentication details as part of the URL is not part of the HTTP RFC in the
first place, but is allowed in a generic URI. RFC 1738 has no mention of
authentication in the syntax of an HTTP URL (see page 8) and its
implementation in browsers has been an exception - much like the
Content-Disposition MIME header that is widely implemented in the HTTP
handling of browsers.

However, if you hover your mouse over such a link you will see the status
bar of the browser still displays the incorrect link. It seems like the
incorrect parsing code is still there, but the current attack vector is
gone - time to look for other pathways.



Regards

Thor Larholm
PGP: 0x5A276569
6BB1 B77F CB62 0D3D 5A82 C65D E1A4 157C 5A27 6569

PivX defines "Proactive Threat Mitigation". Get a FREE Beta Version of
Qwik-Fix <http://www.qwik-fix.net>


-----Original Message-----
From: McAllister, Andrew [mailto:McAllisterA@umsystem.edu]
Sent: Wed 1/28/2004 2:54 PM
To: bugtraq@securityfocus.com
Cc:
Subject: MS to stop allowing passwords in URLs


I just read that Microsoft will stop allowing IDs and passwords to be
embedded in URLs used by Internet Explorer. So you will no longer be
able to use a URL like https://userassword@www.somehost.com/

See http://support.microsoft.com/default...b;en-us;834489

Their reasoning is that this will mitigate status bar spoofing as has
recently been discussed here and in other forums. The article even goes
so far as to admit that recent versions of IE show only the URL before
the @ sign while older versions do not.

Apparently MS has decided that this RFC URL syntax is simply too
dangerous to allow in their products.

Their suggested workarounds include among others:
1) Having users click the "Remember my password" checkbox in IE.
2) Using cookies.

I personally use this syntax in only one production application, BBTray
- a windows tray applet that watches my bigbrother monitoring server.
Click the applet and it opens a browser window with the
idassowrd@server.com syntax. The ID and password is specific to our
bigbrother application, my workstation sits behind two firewalls and I
am the only admin on the box. So, I consider this use to be legit and
relatively safe given the convenience it provides.

I certainly don't consider the "remember my password" functionality nor
stored cookies any more or less safe than this syntax.

Anyone have any comments regarding legitimate uses of this syntax and
Microsoft removing it from their browser? (and presumably the OS since
the browser IS the OS).

Andrew McAllister
University of Missouri

Hello Andrew,

Wednesday, January 28, 2004, 2:54:00 PM, you wrote:

MA> I just read that Microsoft will stop allowing IDs and passwords to be
MA> embedded in URLs used by Internet Explorer. So you will no longer be
MA> able to use a URL like https://userassword@www.somehost.com/

MA> See http://support.microsoft.com/default...b;en-us;834489

MA> Their reasoning is that this will mitigate status bar spoofing as has
MA> recently been discussed here and in other forums.

That reasoning is also in the KB article and the bug in this portion
of IE is obliquely acknowledged.

MA> The article even goes
MA> so far as to admit that recent versions of IE show only the URL before
MA> the @ sign while older versions do not.

The article states the opposite. It states that earlier versions
displayed the entire URL (including authentication parts) whereas IE6
conceals the authentication portion and displays starting with the
hostname. This is, of course, excluding cases that use known flaws in
the URL parsing and is also unique to windows 2003.

MA> Apparently MS has decided that this RFC URL syntax is simply too
MA> dangerous to allow in their products.

If you read the HTTP 1.1 specs closely (RFC 2616) you will find that a
HTTP URL does NOT include the usernameassword in the syntax.

RFC 1738 and RFC 2396 specify the format of "generic" URL's but RFC
1738 specifically refers to RFC 2616 for the format of HTTP URL's.

RFC's 1738 and RFC 2396 both discourage the use of usernameassword
information in URLs as well.

That said, I liked the ability to source-specify login information as
well. I think we may all be just a little shocked to see MS removing
functionality in the interests of security. I wonder if this is
because they were unable to fix the %00 spoofing or had too many other
issues with this syntax.

Another plus is that this change may see an upsurge in the use of
Mozilla, which still supports this syntax.

--
Best regards,
Sam mailto:sschinke@myrealbox.com

"McAllister, Andrew" <McAllisterA@umsystem.edu> wrote:

> I just read that Microsoft will stop allowing IDs and passwords to be
> embedded in URLs used by Internet Explorer. So you will no longer be
> able to use a URL like https://userassword@www.somehost.com/
>
> See http://support.microsoft.com/default...b;en-us;834489

And a good thing too...

You see, rather sadly, MS failed to note in that KB article that this
change _finally_ makes IE's HTTP URL-handling more or less standards-
conforming. How many years is that now since IE 3.0 introduced this
non-standard behaviour?

> Their reasoning is that this will mitigate status bar spoofing as has
> recently been discussed here and in other forums. The article even goes
> so far as to admit that recent versions of IE show only the URL before
> the @ sign while older versions do not.
>
> Apparently MS has decided that this RFC URL syntax is simply too
> dangerous to allow in their products.

It seems you misread the KB article and related RFCs. Admittedly the
KB article seems to have been written be portray MS as the victim of
harrassment by those nasty scammers, but in reality -- whatever MS'
actual or professed reasons for making these changes -- MS has removed
a _mis-feature_ that was not compliant with the agreed industry
standards that IE is supposed to measure up against.

Although that KB article refers the reader to RFC 2616 for further
explanation, it also rather misleadingly refers to RFC 1738 and 2396.
As RFC 2616 specifically covers the HTTP URL syntax in its section
3.2.2, the others are irrelevant to the issue of "What is the proper
syntax of an HTTP URL?". RFC 2616 clearly _does not allow_ the
"userid" component of the generic URI syntax _which is OPTIONAL _AND_
scheme dependent_. Go on, read all three RFCs and see for yourself...

> Their suggested workarounds include among others:
> 1) Having users click the "Remember my password" checkbox in IE.
> 2) Using cookies.
>
> I personally use this syntax in only one production application, BBTray
> - a windows tray applet that watches my bigbrother monitoring server.

Then you should stop because it is not standards compliant. Do you
really want to be part of the problem? (And a problem, that no matter it
is not publicy admitting it is largely responsible for, MS itself is now
trying to distance itself from?)

> Click the applet and it opens a browser window with the
> idassowrd@server.com syntax. The ID and password is specific to our
> bigbrother application, my workstation sits behind two firewalls and I
> am the only admin on the box. So, I consider this use to be legit and
> relatively safe given the convenience it provides.

You're welcome to your opinion, but as a few moments reading the RFCs,
rather than the documention of the devil-spawn of all browsers would have
shown you way back when, it is a poor opinion.

> I certainly don't consider the "remember my password" functionality nor
> stored cookies any more or less safe than this syntax.

Indeed, but at least they cooform to the standards that are supposed to
make the WWW work and interoperate between dozens upon dozens of otherwise
largely incompatible systems.

> Anyone have any comments regarding legitimate uses of this syntax and

No, because there is no legitimate use of that syntax. If MS had
implemented a scheme of its own -- say, "scamsRus" -- and allowed the
userid component of the generic URI as a valid part of that scheme, then
you would certainly be entitled to use a URL of the form:

scamsRus://userassword@www.somehost.com/

but HTTP is defined without such support so you aren't entitled to use it as MS should not have supported it.

> Microsoft removing it from their browser? (and presumably the OS since
> the browser IS the OS).

This is a good thing.

The inconvenience to your relatively few users of their loss of this
non-standard "feature" is worth the reduction in credible-seeming scams
the removal of the feature will see in ensuing years.

And perhaps MS removing this will pressure other browser developers to
follow suit -- after all, who would want their product to be known as
"the browser lagging IE in security features"? 8-)


Regards,

Nick FitzGerald

At 22:54 28/01/2004, McAllister, Andrew wrote:
>I just read that Microsoft will stop allowing IDs and passwords to be
>embedded in URLs used by Internet Explorer. So you will no longer be
>able to use a URL like https://userassword@www.somehost.com/
>
>See http://support.microsoft.com/default...b;en-us;834489

>Anyone have any comments regarding legitimate uses of this syntax and
>Microsoft removing it from their browser? (and presumably the OS since
>the browser IS the OS).

Personally, I think it's a reasonable step - these spoofed URLs are a big
problem for many people.

You can disable the functionality in IE if you wish (the above link has
details)

I think I'd prefer it if you could override it on a site by site basis (eg
using the 'trusted sites' functions, or by having the usernameassword@url
in your IE 'favourites')

(Although, having said that, having spammers use http://username@url is
quite a good trigger to put in email anti-spam rules, as I've never seen
anyone use that format in an email link legitimately..)
Paul VPOP3 - Internet Email Server/Gateway
support@pscs.co.uk http://www.pscs.co.uk/

>>> Anyone have any comments regarding legitimate
>>> uses of this syntax and Microsoft removing it
>>> from their browser? (and presumably the OS since
>>> the browser IS the OS).

It always was a bad idea to put plaintext passwords in URLs because it
encouraged users to give away passwords in links on public Web pages. The
spoofing games were the second big problem with them that showed up later.
Glad to see Microsoft getting rid of the feature.

Richard

On Tue, 3 Feb 2004, Fergus Brooks wrote:

snipped ...
> Also I have found that often to get to an FTP server on the Internet
> (depending on the proxy, connection, firewall etc) that you need to use
> this format. Taking this functionality away will certainly make it
> harder for a lot of support people and consultants to do their jobs.
>
snipped ...

I just applied this patch (KB832894 MS-04-004) to IE 6.0 on W2K to check
handling of ftp url's. After the patch, ftp://usernameassword@site still
works. I think the change only applies to http, https.