Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #243643 > unrolled thread

Firefox: Warning: Potential Security Risk Ahead for the USPS.com

Back to article view | Back to linux.debian.user

Contents

  Firefox: Warning: Potential Security Risk Ahead for the USPS.com local10 <local10@tutanota.com> - 2022-01-03 23:10 +0100
    Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com Roberto C. Sánchez <roberto@debian.org> - 2022-01-03 23:20 +0100
      Re: Firefox: Warning: Potential Security Risk Ahead for the  USPS.com local10 <local10@tutanota.com> - 2022-01-03 23:20 +0100
        Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com Mark Allums <maa@allums.com> - 2022-01-03 23:40 +0100
          Re: Firefox: Warning: Potential Security Risk Ahead for the  USPS.com local10 <local10@tutanota.com> - 2022-01-03 23:50 +0100
        Re: Firefox: Warning: Potential Security Risk Ahead for the  USPS.com local10 <local10@tutanota.com> - 2022-01-03 23:50 +0100
          Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com Dan Ritter <dsr@randomstring.org> - 2022-01-04 00:30 +0100
          Re: Firefox: Warning: Potential Security Risk Ahead for the  USPS.com local10 <local10@tutanota.com> - 2022-01-04 01:00 +0100
          [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for  the USPS.com local10 <local10@tutanota.com> - 2022-01-04 01:10 +0100
            Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for  the USPS.com Michael Stone <mstone@debian.org> - 2022-01-04 19:20 +0100
              Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for  the USPS.com "James H. H. Lampert" <jamesl@touchtonecorp.com> - 2022-01-04 19:40 +0100
                Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for  the USPS.com <tomas@tuxteam.de> - 2022-01-04 19:40 +0100
                Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for  the USPS.com Michael Stone <mstone@debian.org> - 2022-01-04 21:30 +0100
              Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for  the USPS.com <tomas@tuxteam.de> - 2022-01-04 19:40 +0100
                Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for  the USPS.com David Wright <deblis@lionunicorn.co.uk> - 2022-01-04 20:40 +0100
                  Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for  the USPS.com <tomas@tuxteam.de> - 2022-01-04 21:00 +0100
                    Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead  for the USPS.com Celejar <celejar@gmail.com> - 2022-01-04 22:10 +0100
                      Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for  the USPS.com <tomas@tuxteam.de> - 2022-01-05 06:20 +0100
                        Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead  for the USPS.com Celejar <celejar@gmail.com> - 2022-01-05 14:50 +0100
                          Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for  the USPS.com <tomas@tuxteam.de> - 2022-01-05 18:30 +0100
                            Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead  for the USPS.com Celejar <celejar@gmail.com> - 2022-01-05 18:50 +0100
                              Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for  the USPS.com <tomas@tuxteam.de> - 2022-01-05 19:50 +0100
                                Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead  for the USPS.com Celejar <celejar@gmail.com> - 2022-01-05 22:00 +0100
                  Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for  the USPS.com "James H. H. Lampert" <jamesl@touchtonecorp.com> - 2022-01-04 21:00 +0100
                  Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for  the USPS.com Dan Ritter <dsr@randomstring.org> - 2022-01-04 22:30 +0100
                    Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for  the USPS.com <tomas@tuxteam.de> - 2022-01-05 06:20 +0100
                      Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for  the USPS.com Dan Ritter <dsr@randomstring.org> - 2022-01-05 13:50 +0100
              Re: Firefox: Warning: Potential Security Risk Ahead for the  USPS.com local10 <local10@tutanota.com> - 2022-01-04 19:50 +0100
        Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com Dan Ritter <dsr@randomstring.org> - 2022-01-03 23:50 +0100
      Re: Firefox: Warning: Potential Security Risk Ahead for the  USPS.com local10 <local10@tutanota.com> - 2022-01-03 23:50 +0100
    Re: Firefox: Warning: Potential Security Risk Ahead for the  USPS.com Charles Curley <charlescurley@charlescurley.com> - 2022-01-03 23:40 +0100
      Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com Jeremy Ardley <jeremy@ardley.org> - 2022-01-03 23:50 +0100
        Re: Firefox: Warning: Potential Security Risk Ahead for the  USPS.com local10 <local10@tutanota.com> - 2022-01-04 00:30 +0100
          Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com Jeremy Ardley <jeremy@ardley.org> - 2022-01-04 00:40 +0100
            Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com Jeremy Ardley <jeremy@ardley.org> - 2022-01-04 00:50 +0100
            Re: Firefox: Warning: Potential Security Risk Ahead for the  USPS.com local10 <local10@tutanota.com> - 2022-01-04 00:50 +0100
          Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com RP <reyadmin@gmail.com> - 2022-01-04 00:50 +0100
    Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com <tomas@tuxteam.de> - 2022-01-04 07:00 +0100
      [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for  the USPS.com local10 <local10@tutanota.com> - 2022-01-04 13:00 +0100
        Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for  the USPS.com <tomas@tuxteam.de> - 2022-01-04 13:20 +0100
      GUIs (was: Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com) rhkramer@gmail.com - 2022-01-04 15:00 +0100
        Re: GUIs (was: Re: Firefox: Warning: Potential Security Risk Ahead  for the USPS.com) <tomas@tuxteam.de> - 2022-01-04 16:30 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#243730 — Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

On Wed, 5 Jan 2022 18:20:23 +0100
<tomas@tuxteam.de> wrote:

> On Wed, Jan 05, 2022 at 08:43:23AM -0500, Celejar wrote:
> > On Wed, 5 Jan 2022 06:10:48 +0100
> > <tomas@tuxteam.de> wrote:
> > 
> > > On Tue, Jan 04, 2022 at 04:05:11PM -0500, Celejar wrote:
> > > 
> > > [...]
> > > 
> > > > One way "to combine DoH with resolving 14,000 addresses to 127.0.0.1"
> > > > is by using Pi-hole. Some people have *millions* of domains blacklisted
> > > > in Pi-hole:
> > > 
> > > Pi-hole won't help unles it also does HTTPS proxying (that means it
> > > would have to play MITM). As far as I know it "just" does conventional
> > > DNS proxying (which is a great thing to do, mind you).
> > 
> > Why won't it help? What won't it help with?
> 
> (See also Dan's response: it seems that a compliant DoH client first
> sends a local DNS request first, so you might have a handle through
> this)
> 
> With this caveat: how would you intercept a DNS request over HTTPS if
> not by proxying HTTPS traffic? And that is exactly what MITM means.

The configuration I'm talking about is as follows: the browser makes
ordinary, unencrypted DNS requests to the Pi-hole, over a trusted
network (your LAN, or a VPN). HTTPS isn't necessary here insofar as you
trust your own network to be secure. (And if you're really worried about
intruders and sniffers inside your network, you can always run Pi-hole
on the same system as the browser itself (possibly in a container or
VM), although that'll require dedicating some resources to the Pi-hole
installation.)

The Pi-hole then either blocks the request (if the address is on its
blocklists), or looks it up via DoH.

See, e.g., here:

https://www.reddit.com/r/pihole/comments/ku0i8k/configuring_dnsoverhttps_on_pihole/

Celejar

[toc] | [prev] | [next] | [standalone]

#243734 — Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jan 05, 2022 at 12:41:23PM -0500, Celejar wrote:

[...]

> The configuration I'm talking about is as follows: the browser makes
> ordinary, unencrypted DNS requests to the Pi-hole, over a trusted
> network

If the browser decides to make the DNS requests over HTTPS (DoH [1],
that's what we are talking about), the DNS server in your Pi-hole doesn't
even get to see those requests.

>         (your LAN, or a VPN). HTTPS isn't necessary here insofar as you
> trust your own network to be secure. (And if you're really worried about
> intruders [...]

No, no. I'm not worried about those things. I'm worried that the
browsers do their own thing to do name lookup so they escape my control
(be it via /etc/hosts, be it via an own DNS server, local or Pi-hole).

> https://www.reddit.com/r/pihole/comments/ku0i8k/configuring_dnsoverhttps_on_pihole/

Again: I'm not that much concerned about my lookup's privacy. The
Pi-hole having an option to do DoH lookups is fine. But do I trust my
browser to not do direct DoH lookups all by itself, bypassing my Pi-hole
(or whatever I've set up as a controlled DNS)? What about its next
version?

Cheers

[1] Browser folks have decided that making DNS requests over HTTP(S) is
   much more secure than over the "traditional" avenue. In a way, they
   are right. In another they are horribly wrong-
   https://en.wikipedia.org/wiki/DNS_over_HTTPS 

-- 
t

[toc] | [prev] | [next] | [standalone]

#243743 — Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

On Wed, 5 Jan 2022 19:42:33 +0100
<tomas@tuxteam.de> wrote:

> On Wed, Jan 05, 2022 at 12:41:23PM -0500, Celejar wrote:
> 
> [...]
> 
> > The configuration I'm talking about is as follows: the browser makes
> > ordinary, unencrypted DNS requests to the Pi-hole, over a trusted
> > network
> 
> If the browser decides to make the DNS requests over HTTPS (DoH [1],
> that's what we are talking about), the DNS server in your Pi-hole doesn't
> even get to see those requests.

So tell the browser not to use DoH! Am I really being so unclear? My
point is that it's a straightforward matter to get the DNS requests of
your applications - browsers, and all other applications as well -
checked against blocklists, and then sent over DoH if they aren't
blocked by the lists.

> >         (your LAN, or a VPN). HTTPS isn't necessary here insofar as you
> > trust your own network to be secure. (And if you're really worried about
> > intruders [...]
> 
> No, no. I'm not worried about those things. I'm worried that the
> browsers do their own thing to do name lookup so they escape my control
> (be it via /etc/hosts, be it via an own DNS server, local or Pi-hole).

I'm not sure why you're worried about browsers doing their own things
despite your telling them not to, or where anyone mentioned such a
concern in this thread, but if you are worried about that sort of
thing, then I agree that it's pretty much game over. Even if you block
known DoH servers at the firewall, I suppose you can always worry about
browsers contacting some unknown DoH server. And why stop there? Maybe
the browser will do some nefarious phoning home, using some homegrown
protocol, encapsulated inside HTTPS so you'll never know about it! The
bottom line is that yes, if you don't trust your browser and you allow it to
contact arbitrary sites over HTTPS, then it's game over.

> > https://www.reddit.com/r/pihole/comments/ku0i8k/configuring_dnsoverhttps_on_pihole/
> 
> Again: I'm not that much concerned about my lookup's privacy. The
> Pi-hole having an option to do DoH lookups is fine. But do I trust my
> browser to not do direct DoH lookups all by itself, bypassing my Pi-hole
> (or whatever I've set up as a controlled DNS)? What about its next
> version?

Celejar

[toc] | [prev] | [next] | [standalone]

#243699 — Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

On 1/4/22 11:33 AM, David Wright wrote:

> In fact, I was quite shocked when I just tried
> DNS over HTTPS for a couple of minutes. The 10-day weather
> profile that I screenshoot every day was plastered in popups.
> 
> Anyone know how to combine DoH with resolving 14,000 addresses
> to 127.0.0.1? Also, does that mean that DoH attempts to resolve
> my local hosts before consulting /etc/hosts? I didn't stick
> around DoH long enough to find out.

Yeef!

Thoughts of the Homer Simpson catchphrase, and the boss adversary from 
Arkanoid (and its sequel, Revenge of DOH), come to mind.

--
JHHL

[toc] | [prev] | [next] | [standalone]

#243702 — Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

David Wright wrote: 
> On Tue 04 Jan 2022 at 19:37:34 (+0100), tomas@tuxteam.de wrote:
> > On Tue, Jan 04, 2022 at 01:19:37PM -0500, Michael Stone wrote:
> > 
> > [...]
> > 
> > > And this is why putting stuff into /etc/hosts is basically never the right
> > > answer. :)
> > 
> > Eye, beholder and things. I've got a couple of them like so:
> > 
> >   # Pest:
> >   127.0.0.1 www.google-analytics.com
> >   127.0.0.1 ajax.google.com
> >   127.0.0.1 ad.doublecklick.net
> >   127.0.0.1 www.gstatic.com
> >   ...
> > 
> > Yeah, some things stop working then. I want them to :)
> 
> Agreed. I append a list of close to 14,000 addresses (including
> comments) to the end of my own local /etc/hosts. I see very
> few adverts. In fact, I was quite shocked when I just tried
> DNS over HTTPS for a couple of minutes. The 10-day weather
> profile that I screenshoot every day was plastered in popups.
> 
> Anyone know how to combine DoH with resolving 14,000 addresses
> to 127.0.0.1? Also, does that mean that DoH attempts to resolve
> my local hosts before consulting /etc/hosts? I didn't stick
> around DoH long enough to find out.

Here's what I do:

My local DNS resolver offers DNS, DNS over TLS, and DNS over
HTTPS.

I supply a use-application-dns.net zone that returns NXDOMAIN.
That tells browsers to not use DoH.

I build an adblocker zone via a script that grabs several public
lists, and those all return an address that is answered by a web
server that always answers with a 204 (No Content, success).
That's where you get to put your 14,000 addresses.

The adblocker zone gets rebuilt when I feel like it; otherwise,
I could put in a cron job to update it once a month or so.

-dsr-

[toc] | [prev] | [next] | [standalone]

#243705 — Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jan 04, 2022 at 04:09:42PM -0500, Dan Ritter wrote:

[...]

> Here's what I do:
> 
> My local DNS resolver offers DNS, DNS over TLS, and DNS over
> HTTPS.
> 
> I supply a use-application-dns.net zone that returns NXDOMAIN.
> That tells browsers to not use DoH.

Oh, is it possible to tell the browsers which host to ask to resolve DoH
requests? That would be... nice :)

> I build an adblocker zone [...] that always answers with a 204 [...]

nice

Thanks
-- 
t

[toc] | [prev] | [next] | [standalone]

#243707 — Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

tomas@tuxteam.de wrote: 
> On Tue, Jan 04, 2022 at 04:09:42PM -0500, Dan Ritter wrote:
> 
> [...]
> 
> > Here's what I do:
> > 
> > My local DNS resolver offers DNS, DNS over TLS, and DNS over
> > HTTPS.
> > 
> > I supply a use-application-dns.net zone that returns NXDOMAIN.
> > That tells browsers to not use DoH.
> 
> Oh, is it possible to tell the browsers which host to ask to resolve DoH
> requests? That would be... nice :)

Not precisely which host. A compliant DoH client (FF, Chrome) is supposed to
start by asking local DNS for a record from
use-application-dns.net, which Mozilla runs. If your DNS server has
use-application-dns.net and insists on returning NXDOMAIN, then
the client should fall back to using whatever DNS the operating
system supplies.

In Bullseye, unbound has support for both DNS-over-TLS and
DNS-over-HTTPS -- the latter is new.

> > I build an adblocker zone [...] that always answers with a 204 [...]
> 
> nice

Pick an IP in your local net - let's say, 10.0.0.254. Use that
as your DNS response instead of 127.0.0.1. This will work just
fine in /etc/hosts.

Make sure you have a machine listening to 10.0.0.254, and set up
a web server to answer regardless of name. 

For nginx:

server {
	listen 10.0.0.254:80;
	server_name _;

	root /var/www/blank;
	index blank.png;

	rewrite .+?(png|gif|jpe?g)$ /blankimg last;
	rewrite ^(.*)$ / last;

	location / {
              return 204;
	}

	location /blankimg {
		empty_gif; # See http://nginx.org/en/docs/http/ngx_http_empty_gif_module.html
	}
}

So if the page asks for an image, I supply a 1x1 transparent dot.
If it asks for anything else, 204, which is not an error.


-dsr-

[toc] | [prev] | [next] | [standalone]

#243694 — Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

Jan 4, 2022, 18:19 by mstone@debian.org:

> And this is why putting stuff into /etc/hosts is basically never the right answer. :)
>

I think it's fine as long as one is aware of what one is doing. I should have caught it sooner but due to other circumstances I was under a false impression that the issue was external so I was looking for a solution in the wrong place.

Regards,

[toc] | [prev] | [next] | [standalone]

#243652

local10 wrote: 
> Jan 3, 2022, 22:11 by roberto@debian.org:
> 
> > The site works fine for me.
> >
> > In FF, click on 'SSL_ERROR_BAD_CERT_DOMAIN', which should take you to
> > the full error output.  Then click 'Copy text to clipboard' and paste
> > the full text into an email.  Someone on the list ought to be able to
> > help diagnose further from there.
> >
> 
> 
> Weird. This is what I get:
> 
> 
> Websites prove their identity via certificates. Firefox does not trust this site because it uses a certificate that is not valid for tools.usps.com. The certificate is only valid for the following names: www.costco.ca <http://www.costco.ca>, costco.ca
> 

Costco is definitely not the US Postal Service.

flush caches. Restart Firefox. Check your net connection.

-dsr-

[toc] | [prev] | [next] | [standalone]

#243649 — Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

Jan 3, 2022, 22:16 by local10@tutanota.com:

> Jan 3, 2022, 22:11 by roberto@debian.org:
>
>> The site works fine for me.
>>
>> In FF, click on 'SSL_ERROR_BAD_CERT_DOMAIN', which should take you to
>> the full error output.  Then click 'Copy text to clipboard' and paste
>> the full text into an email.  Someone on the list ought to be able to
>> help diagnose further from there.
>>
>
>
> Weird. This is what I get:
>
>
> Websites prove their identity via certificates. Firefox does not trust this site because it uses a certificate that is not valid for tools.usps.com. The certificate is only valid for the following names: www.costco.ca <http://www.costco.ca>, costco.ca
>
> Error code: SSL_ERROR_BAD_CERT_DOMAIN
>
>
> https://tools.usps.com/go/TrackConfirmAction_input?origTrackNum=1234567890
>
> Unable to communicate securely with peer: requested domain name does not match the server’s certificate.
>
> HTTP Strict Transport Security: false
> HTTP Public Key Pinning: false
>
> Certificate chain:
>
> ...
>

More info:

# cat /etc/debian_version && uname -a
11.2
Linux srv07 5.10.0-10-amd64 #1 SMP Debian 5.10.84-1 (2021-12-08) x86_64 GNU/Linux


# aptitude show firefox-esr
Package: firefox-esr                    
Version: 91.4.1esr-1~deb11u1
New: yes
State: installed

[toc] | [prev] | [next] | [standalone]

#243646 — Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

On Mon, 3 Jan 2022 23:01:34 +0100 (CET)
local10 <local10@tutanota.com> wrote:

> Am I the only one who's getting this error?

I am not. Vivaldi (vivaldi-stable, 5.0.2497.32-1, amd64) on bullseye.
The cert looks like:

Common Name (CN)	*.usps.com
Organization (O)	United States Postal Service
Organizational Unit (OU)	<Not Part Of Certificate>
Common Name (CN)	DigiCert SHA2 Secure Server CA
Organization (O)	DigiCert Inc
Organizational Unit (OU)	<Not Part Of Certificate>
Issued On	Wednesday, May 13, 2020 at 6:00:00 PM
Expires On	Monday, May 16, 2022 at 6:00:00 AM
SHA-256 Fingerprint	AA 8B 94 FA D6 4D 4B 79 AE A3 23 03 78 B2 E4 97
65 8A C8 C2 CC B2 3A EC 09 C0 88 03 A9 36 26 E6
SHA-1 Fingerprint	7F 13 43 BD 73 38 23 15 81 A8 54 11 C3 13 F4 95
12 81 96 1F


-- 
Does anybody read signatures any more?

https://charlescurley.com
https://charlescurley.com/blog/

[toc] | [prev] | [next] | [standalone]

#243648

[Multipart message — attachments visible in raw view] — view raw

On 4/1/22 6:36 am, Charles Curley wrote:
> On Mon, 3 Jan 2022 23:01:34 +0100 (CET)
> local10 <local10@tutanota.com> wrote:
>
>> Am I the only one who's getting this error?
> I am not. Vivaldi (vivaldi-stable, 5.0.2497.32-1, amd64) on bullseye.
> The cert looks like:
>
> Common Name (CN)	*.usps.com
> Organization (O)	United States Postal Service
> Organizational Unit (OU)	<Not Part Of Certificate>
> Common Name (CN)	DigiCert SHA2 Secure Server CA
> Organization (O)	DigiCert Inc
> Organizational Unit (OU)	<Not Part Of Certificate>
> Issued On	Wednesday, May 13, 2020 at 6:00:00 PM
> Expires On	Monday, May 16, 2022 at 6:00:00 AM
> SHA-256 Fingerprint	AA 8B 94 FA D6 4D 4B 79 AE A3 23 03 78 B2 E4 97
> 65 8A C8 C2 CC B2 3A EC 09 C0 88 03 A9 36 26 E6
> SHA-1 Fingerprint	7F 13 43 BD 73 38 23 15 81 A8 54 11 C3 13 F4 95
> 12 81 96 1F
>
>
I too have no problems.

My best guess is the OP DNS has been compromised. A simple check such as 
using the host command should produce

host usps.com
usps.com has address 56.0.134.100
usps.com mail is handled by 10 usps-com.mail.protection.outlook.com.

host tools.usps.com
tools.usps.com is an alias for cs1799.wpc.upsiloncdn.net.
cs1799.wpc.upsiloncdn.net has address 68.232.45.196
cs1799.wpc.upsiloncdn.net has IPv6 address 
2606:2800:10c:b15a:cfbd:99c7:4c90:f5a0


-- 
Jeremy

[toc] | [prev] | [next] | [standalone]

#243654 — Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

Jan 3, 2022, 22:42 by jeremy@ardley.org:

> I too have no problems.
>
> My best guess is the OP DNS has been compromised. A simple check such as using the host command should produce
>
> host usps.com
> usps.com has address 56.0.134.100
> usps.com mail is handled by 10 usps-com.mail.protection.outlook.com.
>
> host tools.usps.com
> tools.usps.com is an alias for cs1799.wpc.upsiloncdn.net.
> cs1799.wpc.upsiloncdn.net has address 68.232.45.196
> cs1799.wpc.upsiloncdn.net has IPv6 address 2606:2800:10c:b15a:cfbd:99c7:4c90:f5a0
>


I have no problems accessing the www.usps.com <http://www.usps.com>, it's when I go to tools.usps.com that's when I have the issue:

# host usps.com
usps.com has address 56.0.134.100
usps.com mail is handled by 10 usps-com.mail.protection.outlook.com.

# host tools.usps.com
tools.usps.com is an alias for cs1799.wpc.upsiloncdn.net.
cs1799.wpc.upsiloncdn.net has address 152.195.33.23
cs1799.wpc.upsiloncdn.net has IPv6 address 2606:2800:21f:3e9e:5a:9b8f:bddb:fb7c


# dig tools.usps.com

; <<>> DiG 9.16.22-Debian <<>> tools.usps.com
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42248
;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
; COOKIE: cf068e81706948620100000061d38628fa25caed2103d635 (good)
;; QUESTION SECTION:
;tools.usps.com.                        IN      A

;; ANSWER SECTION:
tools.usps.com.         18      IN      CNAME   cs1799.wpc.upsiloncdn.net.
cs1799.wpc.upsiloncdn.net. 3320 IN      A       152.195.33.23

;; Query time: 0 msec
;; SERVER: 127.0.0.1#53(127.0.0.1)
;; WHEN: Mon Jan 03 18:26:32 EST 2022
;; MSG SIZE  rcvd: 126




# dig  cs1799.wpc.upsiloncdn.net +trace

; <<>> DiG 9.16.22-Debian <<>> cs1799.wpc.upsiloncdn.net +trace
;; global options: +cmd
.                       518224  IN      NS      m.root-servers.net.
.                       518224  IN      NS      a.root-servers.net.
.                       518224  IN      NS      e.root-servers.net.
.                       518224  IN      NS      i.root-servers.net.
.                       518224  IN      NS      j.root-servers.net.
.                       518224  IN      NS      b.root-servers.net.
.                       518224  IN      NS      l.root-servers.net.
.                       518224  IN      NS      f.root-servers.net.
.                       518224  IN      NS      d.root-servers.net.
.                       518224  IN      NS      h.root-servers.net.
.                       518224  IN      NS      c.root-servers.net.
.                       518224  IN      NS      k.root-servers.net.
.                       518224  IN      NS      g.root-servers.net.
.                       518224  IN      RRSIG   NS 8 0 518400 20220116170000 20220103160000 9799 . WGsxB2AU5BQlYBqTc+eA4/0rvPyoftZEEHbFYipdp6K2wCpKecBnnrEE 8/HdGAxK0gXRcgfylPCxsces7/ZAVclppfpnAPg+iiwm/y+ngRvr1EE4 H9EQzJJKHvsnWfZhCeYOzKt868Sq7xTMHYSCMs26WKFitM/BQW4J354O lgzhsB/303j1HnT7QRY+byRHNaXKsh8G1P6cHBMZkOKGuyCtMGX+jNmU CnIxzgHrWjxde+mJ9SJKfHxWh1ZqsL9QWyyE00qeriwkF0kMO0W7Pjtj +2zlsXD6jjo7Y8SjjOctDLTNJPa2XvKCnRuhgSV1mBN0Hdz8CH5RQ0O4 3UacTQ==
;; Received 1137 bytes from 127.0.0.1#53(127.0.0.1) in 0 ms

net.                    172800  IN      NS      a.gtld-servers.net.
net.                    172800  IN      NS      b.gtld-servers.net.
net.                    172800  IN      NS      c.gtld-servers.net.
net.                    172800  IN      NS      d.gtld-servers.net.
net.                    172800  IN      NS      e.gtld-servers.net.
net.                    172800  IN      NS      f.gtld-servers.net.
net.                    172800  IN      NS      g.gtld-servers.net.
net.                    172800  IN      NS      h.gtld-servers.net.
net.                    172800  IN      NS      i.gtld-servers.net.
net.                    172800  IN      NS      j.gtld-servers.net.
net.                    172800  IN      NS      k.gtld-servers.net.
net.                    172800  IN      NS      l.gtld-servers.net.
net.                    172800  IN      NS      m.gtld-servers.net.
net.                    86400   IN      DS      35886 8 2 7862B27F5F516EBE19680444D4CE5E762981931842C465F00236401D 8BD973EE
net.                    86400   IN      RRSIG   DS 8 1 86400 20220116170000 20220103160000 9799 . lV9LChf+ZmsGC84XLyLtzCaRA5Z/HIy3xlhxVYKPCeE6Zj2wK6dyFk3p zTxto9XYVbuzwDD26zLLOkD27b8NBEnSVucdkVB+8fKAz/Y188eoCua/ CqYODHbyAT85QKUwBalN21PzORXMdMqf4Yp0LkqX6SeVvNlkCaOSk4CJ oP/q8chESaMFJ5WUeexXSdHCUpwMRbPpI+0U3E3ctTRpNtUAPQOtOnMN ZawH9eaXFpc2Vxitid/4SZt3nNYm2oaHX7IhBd3+JCp9q05tMfkFEDve 21SrA3V6322E9xPa2FA3DLEb+ib7QLIuf9V8FxuhcRae3veVHwsoeZ6H ckrP8A==
;; Received 1210 bytes from 199.9.14.201#53(b.root-servers.net) in 139 ms

upsiloncdn.net.         172800  IN      NS      ns1.upsiloncdn.net.
upsiloncdn.net.         172800  IN      NS      ns2.upsiloncdn.net.
upsiloncdn.net.         172800  IN      NS      ns3.upsiloncdn.net.
upsiloncdn.net.         172800  IN      NS      ns4.upsiloncdn.net.
A1RT98BS5QGC9NFI51S9HCI47ULJG6JH.net. 86400 IN NSEC3 1 1 0 - A1RTLNPGULOGN7B9A62SHJE1U3TTP8DR NS SOA RRSIG DNSKEY NSEC3PARAM
A1RT98BS5QGC9NFI51S9HCI47ULJG6JH.net. 86400 IN RRSIG NSEC3 8 2 86400 20220107064644 20211231053644 40649 net. D3BLYRX8S4zPDf4yLHikma0f1apx6u6kokIv7t/G7YfNh1NjScepzXFN uYmgvO2Ssw+t51DrpwdU9Kg4ljdzvEIHn1VVbVTpYkLMC4sjRpcVOzLX ATIH8TYbvbBYSTV8drWowBwIrLMar7YnHkyjtQjBx1dsX0bpE8k3BTsk 7Mo5Q/9Y0Bl6iw158iDKXPEOWK3ZdSXMYpizDr+edlvaFQ==
OB6AS2VF8R52HAJS5DOOMOSDPMJ81D2H.net. 86400 IN NSEC3 1 1 0 - OB6BU1JEL3OVBLGK4Q599CV5C8F8P4TV NS DS RRSIG
OB6AS2VF8R52HAJS5DOOMOSDPMJ81D2H.net. 86400 IN RRSIG NSEC3 8 2 86400 20220108064033 20220101053033 40649 net. eqc+FVbEZVB2tsD448YpegmlRYE1dCT0TR/NR3k4OWMAJR54SMw0uAIx viYvtlWXhGipJ7LLPKX6x87E/hUS7DITHQ1IVGKKHZe1l0ghLT7QP25X s2JBHcMXOSiZaklSr5f+pBUD3HcpTO3FB2qjkk7l/JnDKcQ6sdBO3FlS wHaSGQySfIVMEXBMFi5VpdQHrszYuJ+A8hK6pp9lmKza0g==
;; Received 851 bytes from 192.35.51.30#53(f.gtld-servers.net) in 75 ms

cs1799.wpc.upsiloncdn.net. 3600 IN      A       152.195.33.23
;; Received 70 bytes from 72.21.80.6#53(ns2.upsiloncdn.net) in 55 ms


Regards,

[toc] | [prev] | [next] | [standalone]

#243655

[Multipart message — attachments visible in raw view] — view raw

On 4/1/22 7:27 am, local10 wrote:
>
>
> I have no problems accessing the www.usps.com <http://www.usps.com>, it's when I go to tools.usps.com that's when I have the issue:
>
> # host usps.com
> usps.com has address 56.0.134.100
> usps.com mail is handled by 10 usps-com.mail.protection.outlook.com.
>
> # host tools.usps.com
> tools.usps.com is an alias for cs1799.wpc.upsiloncdn.net.
> cs1799.wpc.upsiloncdn.net has address 152.195.33.23
> cs1799.wpc.upsiloncdn.net has IPv6 address 2606:2800:21f:3e9e:5a:9b8f:bddb:fb7c
>
>
>
The IPV6 address you list for tools.usps.com is wildly different from 
the one I get. It's a completely different network - though that may be 
a result of resilience planning.

If you are running IPV6 it may be informative to block it at the 
firewall (I don't know of any way to block it in the browser)

The scenario I'm exploring is you may have a bad upstream IPv6 DNS server

-- 
Jeremy

[toc] | [prev] | [next] | [standalone]

#243657

[Multipart message — attachments visible in raw view] — view raw

On 4/1/22 7:37 am, Jeremy Ardley wrote:
>
> On 4/1/22 7:27 am, local10 wrote:
>>
>>
>> I have no problems accessing the www.usps.com <http://www.usps.com>, 
>> it's when I go to tools.usps.com that's when I have the issue:
>>
>> # host usps.com
>> usps.com has address 56.0.134.100
>> usps.com mail is handled by 10 usps-com.mail.protection.outlook.com.
>>
>> # host tools.usps.com
>> tools.usps.com is an alias for cs1799.wpc.upsiloncdn.net.
>> cs1799.wpc.upsiloncdn.net has address 152.195.33.23
>> cs1799.wpc.upsiloncdn.net has IPv6 address 
>> 2606:2800:21f:3e9e:5a:9b8f:bddb:fb7c
>>
>>
>>
> The IPV6 address you list for tools.usps.com is wildly different from 
> the one I get. It's a completely different network - though that may 
> be a result of resilience planning.
>
> If you are running IPV6 it may be informative to block it at the 
> firewall (I don't know of any way to block it in the browser)
>
> The scenario I'm exploring is you may have a bad upstream IPv6 DNS server
>

Turns out there is a way to stop IPv6 in Firefox

https://techglimpse.com/disable-enable-ipv6-firefox-chrome-browser/


-- 
Jeremy

[toc] | [prev] | [next] | [standalone]

#243658 — Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

Jan 3, 2022, 23:37 by jeremy@ardley.org:

> If you are running IPV6 
>

Not running IPV6.

Regards,

[toc] | [prev] | [next] | [standalone]

#243656

[Multipart message — attachments visible in raw view] — view raw

> # host usps.com
> usps.com has address 56.0.134.100
> usps.com mail is handled by 10 usps-com.mail.protection.outlook.com.
>
> # host tools.usps.com
> tools.usps.com is an alias for cs1799.wpc.upsiloncdn.net.
> cs1799.wpc.upsiloncdn.net has address 152.195.33.23
> cs1799.wpc.upsiloncdn.net has IPv6 address 2606:2800:21f:3e9e:5a:9b8f:bddb:fb7c
>
>
> # dig tools.usps.com
>
> ; <<>> DiG 9.16.22-Debian <<>> tools.usps.com
> ;; global options: +cmd
> ;; Got answer:
> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 42248
> ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1
>
> ;; OPT PSEUDOSECTION:
> ; EDNS: version: 0, flags:; udp: 1232
> ; COOKIE: cf068e81706948620100000061d38628fa25caed2103d635 (good)
> ;; QUESTION SECTION:
> ;tools.usps.com.                        IN      A
>
> ;; ANSWER SECTION:
> tools.usps.com.         18      IN      CNAME   cs1799.wpc.upsiloncdn.net.
> cs1799.wpc.upsiloncdn.net. 3320 IN      A       152.195.33.23
>
> ;; Query time: 0 msec
> ;; SERVER: 127.0.0.1#53(127.0.0.1)
> ;; WHEN: Mon Jan 03 18:26:32 EST 2022
> ;; MSG SIZE  rcvd: 126

Have you tried a different browser?

[toc] | [prev] | [next] | [standalone]

#243673

[Multipart message — attachments visible in raw view] — view raw

On Mon, Jan 03, 2022 at 11:01:34PM +0100, local10 wrote:
> Hi,
> 
> Am I the only one who's getting this error? When I go to the USPS.com[1] to track a package I get this "Warning: Potential Security Risk Ahead" error ( Error code: SSL_ERROR_BAD_CERT_DOMAIN ). It's been like this for a couple of weeks for me so it looks really strange that the USPS has fixed it after all this time.
> I tried the same URL[1] in Konqueror and it also complains about the bad certificate.
> 
> Any ideas? Thanks
> 
> 
> 1 .https://tools.usps.com/go/TrackConfirmAction_input?origTrackNum=1234567890

Seems to work for me (currently). Are you still getting the error?

The error means that the site was offering a cert for the wrong domain.
This could happen for a whole bunch of reasons, someone fat-fingering
something at the server end, someone forgetting to hand out the cert to
the CDN, whatever.

If the error persists on your side, you can try to dig into it by
clicking [1] on the security thingie to the left of the URL bar, then
your browser offers more info about the server cert.

Cheers

[1] Don't you hate GUIs? Describing how to do a simple thing ends up in
   reams of difficult-to-understand text.

-- 
tomás

[toc] | [prev] | [next] | [standalone]

#243677 — [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

Jan 4, 2022, 05:58 by tomas@tuxteam.de:

> Seems to work for me (currently). Are you still getting the error?
>


Not anymore, it has been solved: https://lists.debian.org/debian-user/2022/01/msg00096.html

 Thanks to everyone who responded.

[toc] | [prev] | [next] | [standalone]

#243679 — Re: [SOLVED] Re: Firefox: Warning: Potential Security Risk Ahead for the USPS.com

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jan 04, 2022 at 12:50:39PM +0100, local10 wrote:
> Jan 4, 2022, 05:58 by tomas@tuxteam.de:
> 
> > Seems to work for me (currently). Are you still getting the error?
> >
> 
> 
> Not anymore, it has been solved: https://lists.debian.org/debian-user/2022/01/msg00096.html
> 
>  Thanks to everyone who responded.

Thanks, yes, I fllowed the thread :)

Cheers
-- 
t

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | linux.debian.user

csiph-web