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

[local10]

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

[local10]

Jan 3, 2022, 22:11 by rob...@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=123456789
0

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:

-----BEGIN CERTIFICATE-----
MIIHTjCCBjagAwIBAgIQBOyIfmSb5tyeC53E3AQoqzANBgkqhkiG9w0BAQsFADB1
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMTQwMgYDVQQDEytEaWdpQ2VydCBTSEEyIEV4dGVuZGVk
IFZhbGlkYXRpb24gU2VydmVyIENBMB4XDTIwMDQxMzAwMDAwMFoXDTIyMDcxMjEy
MDAwMFowgdsxHTAbBgNVBA8MFFByaXZhdGUgT3JnYW5pemF0aW9uMRMwEQYLKwYB
BAGCNzwCAQMTAlVTMRswGQYLKwYBBAGCNzwCAQITCldhc2hpbmd0b24xFDASBgNV
BAUTCzYwMSAwMjQgNjc0MQswCQYDVQQGEwJVUzETMBEGA1UECBMKV2FzaGluZ3Rv
bjERMA8GA1UEBxMISXNzYXF1YWgxJTAjBgNVBAoTHENvc3RjbyBXaG9sZXNhbGUg
Q29ycG9yYXRpb24xFjAUBgNVBAMTDXd3dy5jb3N0Y28uY2EwggEiMA0GCSqGSIb3
DQEBAQUAA4IBDwAwggEKAoIBAQDaZN4KpbA4DhbWw+TT9c8mNUPeVKsYaysqMKJK
jVUKCx4DfAa1xWdR3l/DcMfuA3oTfFhf1X9tpL7hcCQN+jr/WKKTR9usHzjFzP1O
Q8QXPza0HjOaQbLwlO6MMrLfO/R5p1D2dhTAnGneL0ZR03DoqLIPqJT/aBEvQC2C
D5wxtm1TbooHuQ3OeUW8kOp/UY/+mT3uuf1LBz5EdjJ8A0Kc5FX6Lo54vK5Jty4X
VWASsj8W5DkLVL5k6zMUpRqKx9LEb1mYnKxYcTUQetCRBVo3zv7QUb+xNjhwEIiB
qe8g7pFgTW5FORITPoeWLCS68YwxZ/DJ7jYnouQludCKEsaPAgMBAAGjggNxMIID
bTAfBgNVHSMEGDAWgBQ901Cl1qCt7vNKYApl0yHU+PjWDzAdBgNVHQ4EFgQU34QV
E4cZWcbn/7IWLK0nuAzCU9YwIwYDVR0RBBwwGoINd3d3LmNvc3Rjby5jYYIJY29z
dGNvLmNhMA4GA1UdDwEB/wQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDAQYIKwYB
BQUHAwIwdQYDVR0fBG4wbDA0oDKgMIYuaHR0cDovL2NybDMuZGlnaWNlcnQuY29t
L3NoYTItZXYtc2VydmVyLWcyLmNybDA0oDKgMIYuaHR0cDovL2NybDQuZGlnaWNl
cnQuY29tL3NoYTItZXYtc2VydmVyLWcyLmNybDBLBgNVHSAERDBCMDcGCWCGSAGG
/WwCATAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5jb20vQ1BT
MAcGBWeBDAEBMIGIBggrBgEFBQcBAQR8MHowJAYIKwYBBQUHMAGGGGh0dHA6Ly9v
Y3NwLmRpZ2ljZXJ0LmNvbTBSBggrBgEFBQcwAoZGaHR0cDovL2NhY2VydHMuZGln
aWNlcnQuY29tL0RpZ2lDZXJ0U0hBMkV4dGVuZGVkVmFsaWRhdGlvblNlcnZlckNB
LmNydDAJBgNVHRMEAjAAMIIBewYKKwYBBAHWeQIEAgSCAWsEggFnAWUAdQCkuQmQ
tBhYFIe7E6LMZ3AKPDWYBPkb37jjd80OyA3cEAAAAXF1Ht6gAAAEAwBGMEQCIDR/
YSEr0iSj2uKBMQuc3YmvbFjlwH2+uEmd6NNbi9wGAiBTrfdlBpZJN6GyKMqded5g
yCxxgCV4jUtLQiw7vBUN2gB1AFYUBpov18Ls0/XhvUSyPsdGdrm8mRFcwO+UmFXW
idDdAAABcXUe3vcAAAQDAEYwRAIgJKh7x+t4g47X35aah89yser+f77yFRGzp9sj
6WryR2sCIHOa8cSDFzjBwPp3vTHAse1lJO4QGPtg/NXXfk4Veb75AHUAu9nfvB+K
cbWTlCOXqpJ7RzhXlQqrUugakJZkNo4e0YUAAAFxdR7etQAABAMARjBEAiBqwSAH
8sKPb4Y818r3AtnliGWrGhqgtZ0GEZWyDGf+eAIgYYVrZ8xAfrWu83TLSHemxk1E
XvOQ9k8JJHyjVRmOxpQwDQYJKoZIhvcNAQELBQADggEBAGjuhZ9ypCuzqFPHmafF
8tSty5Fb/LsQQ5i6O2A8lgG33WinpVjYbmDvlCl3vEsdkEvarGjCihJgTsb0RwZs
cNBkoFr+kNiR4lm/YnhtAd0qv8+uLJzZ1i9MmhcKuOSTgIKw368Kh0i9C3xDlsPU
jxK1rASaJxAuYBNWcPsnrO/BipRlpK8DG6XlNIUn8PzsuTVNOVf+kjdoM0rAHhVG
kagbhBbKJFLSOqLAZiXgc954wy9VIkEUHOd6Z3asMamTFSyC7wPj6rD3tkGwKKc0
NQO6pYEvkXJRJeieYtla+a+Luly3Nxi8yHWDl98N6sqKgitjCBScs4bWaILw54E3
S1c=
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
MIIEtjCCA56gAwIBAgIQDHmpRLCMEZUgkmFf4msdgzANBgkqhkiG9w0BAQsFADBs
MQswCQYDVQQGEwJVUzEVMBMGA1UEChMMRGlnaUNlcnQgSW5jMRkwFwYDVQQLExB3
d3cuZGlnaWNlcnQuY29tMSswKQYDVQQDEyJEaWdpQ2VydCBIaWdoIEFzc3VyYW5j
ZSBFViBSb290IENBMB4XDTEzMTAyMjEyMDAwMFoXDTI4MTAyMjEyMDAwMFowdTEL
MAkGA1UEBhMCVVMxFTATBgNVBAoTDERpZ2lDZXJ0IEluYzEZMBcGA1UECxMQd3d3
LmRpZ2ljZXJ0LmNvbTE0MDIGA1UEAxMrRGlnaUNlcnQgU0hBMiBFeHRlbmRlZCBW
YWxpZGF0aW9uIFNlcnZlciBDQTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC
ggEBANdTpARR+JmmFkhLZyeqk0nQOe0MsLAAh/FnKIaFjI5j2ryxQDji0/XspQUY
uD0+xZkXMuwYjPrxDKZkIYXLBxA0sFKIKx9om9KxjxKws9LniB8f7zh3VFNfgHk/
LhqqqB5LKw2rt2O5Nbd9FLxZS99RStKh4gzikIKHaq7q12TWmFXo/a8aUGxUvBHy
/Urynbt/DvTVvo4WiRJV2MBxNO723C3sxIclho3YIeSwTQyJ3DkmF93215SF2AQh
cJ1vb/9cuhnhRctWVyh+HA1BV6q3uCe7seT6Ku8hI3UarS2bhjWMnHe1c63YlC3k
8wyd7sFOYn4XwHGeLN7x+RAoGTMCAwEAAaOCAUkwggFFMBIGA1UdEwEB/wQIMAYB
Af8CAQAwDgYDVR0PAQH/BAQDAgGGMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF
BQcDAjA0BggrBgEFBQcBAQQoMCYwJAYIKwYBBQUHMAGGGGh0dHA6Ly9vY3NwLmRp
Z2ljZXJ0LmNvbTBLBgNVHR8ERDBCMECgPqA8hjpodHRwOi8vY3JsNC5kaWdpY2Vy
dC5jb20vRGlnaUNlcnRIaWdoQXNzdXJhbmNlRVZSb290Q0EuY3JsMD0GA1UdIAQ2
MDQwMgYEVR0gADAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy5kaWdpY2VydC5j
b20vQ1BTMB0GA1UdDgQWBBQ901Cl1qCt7vNKYApl0yHU+PjWDzAfBgNVHSMEGDAW
gBSxPsNpA/i/RwHUmCYaCALvY2QrwzANBgkqhkiG9w0BAQsFAAOCAQEAnbbQkIbh
hgLtxaDwNBx0wY12zIYKqPBKikLWP8ipTa18CK3mtlC4ohpNiAexKSHc59rGPCHg
4xFJcKx6HQGkyhE6V6t9VypAdP3THYUYUN9XR3WhfVUgLkc3UHKMf4Ib0mKPLQNa
2sPIoc4sUqIAY+tzunHISScjl2SFnjgOrWNoPLpSgVh5oywM395t6zHyuqB8bPEs
1OG9d4Q3A84ytciagRpKkk47RpqF/oOi+Z6Mo8wNXrM9zwR4jxQUezKcxwCmXMS1
oVWNWlZopCJwqjyBcdmdqEU79OX2olHdx3ti6G8MdOu42vi/hw15UJGQmxg7kVkn
8TUoE6smftX3eg==
-----END CERTIFICATE-----

[Roberto C. Sánchez]

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
>

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.

Regards,

-Roberto

--
Roberto C. Sánchez

[Charles Curley]

On Mon, 3 Jan 2022 23:01:34 +0100 (CET)
local10 <loc...@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/

[Mark Allums]

Did you click on a phishing link?

Mark Allums

[Jeremy Ardley]

On 4/1/22 6:36 am, Charles Curley wrote:
> On Mon, 3 Jan 2022 23:01:34 +0100 (CET)
> local10 <loc...@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

[local10]

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

> Jan 3, 2022, 22:11 by rob...@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

[local10]

Jan 3, 2022, 22:29 by d...@randomstring.org:

> Costco is definitely not the US Postal Service.
>

No argument here.


> flush caches. Restart Firefox. Check your net connection.
>

I've done this a number of times. The connection is direct, no proxy.

Regards,

[local10]

Jan 3, 2022, 22:30 by m...@allums.com:

> Did you click on a phishing link?
>
> Mark Allums
>

No, I have some USPS.com tracking links bookmarked and they were working fine until about two weeks ago. Could it be perhaps related to the Firefox upgrade from 78esr to 91esr?

Regards,

[Dan Ritter]

local10 wrote:
> Jan 3, 2022, 22:11 by rob...@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-

[local10]

Jan 3, 2022, 22:42 by jer...@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,

[Dan Ritter]

Alright. Put this into your /etc/hosts temporarily:

152.195.33.23 www.usps.com tools.usps.com www.usps.gov

That's unlikely to be an optimal IP from their CDN, but it is
currently working.

Oh. Are you using DNS-over-HTTPS?

https://support.mozilla.org/en-US/kb/firefox-dns-over-https

-dsr-

[Jeremy Ardley]

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

[RP]

Have you tried a different browser?

[Jeremy Ardley]

Turns out there is a way to stop IPv6 in Firefox

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


--
Jeremy

[local10]

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

> If you are running IPV6
>

Not running IPV6.

Regards,

[local10]

Jan 3, 2022, 23:08 by d...@randomstring.org:

> Alright. Put this into your /etc/hosts temporarily:
>
> 152.195.33.23 www.usps.com tools.usps.com www.usps.gov
>
> That's unlikely to be an optimal IP from their CDN, but it is
> currently working.
>

That fixed it, I got the USPS tracking page to load normally. Still not why it worked as tools.usps.com resolves for me to 152.195.33.23:

# dig tools.usps.com

; <<>> DiG 9.16.22-Debian <<>> tools.usps.com
;; global options: +cmd
;; Got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 45738

;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232

; COOKIE: 77e474050843f63a0100000061d38b021b182f925c475f14 (good)

;; QUESTION SECTION:
;tools.usps.com.                        IN      A

;; ANSWER SECTION:

tools.usps.com.         42      IN      CNAME   cs1799.wpc.upsiloncdn.net.
cs1799.wpc.upsiloncdn.net. 2078 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:47:14 EST 2022
;; MSG SIZE  rcvd: 126

> Oh. Are you using DNS-over-HTTPS?
>

I used to but I have disabled it for now. Even with DNS-over-HTTPS disabled I was getting the certificate error until I put 152.195.33.23 into the /etc/hosts.


Regards,

[local10]

Jan 3, 2022, 23:53 by loc...@tutanota.com:

> Jan 3, 2022, 23:08 by d...@randomstring.org:
>
>> Alright. Put this into your /etc/hosts temporarily:
>>
>> 152.195.33.23 www.usps.com tools.usps.com www.usps.gov
>>
>> That's unlikely to be an optimal IP from their CDN, but it is
>> currently working.
>>
>

> That fixed it, I got the USPS tracking page to load normally. Still not sure why it worked as tools.usps.com resolves for me to 152.195.33.23:
>
> # dig tools.usps.com
> ...
> ....

> ;; ANSWER SECTION:
> tools.usps.com.         42      IN      CNAME   cs1799.wpc.upsiloncdn.net.
> cs1799.wpc.upsiloncdn.net. 2078 IN      A       152.195.33.23
>

OK, I understand now what the problem was. Quite a while ago I added a line into the /etc/hosts to fix a temp DNS issue and completely forgot about it. So while DNS server was correctly resolving tools.usps.com to 152.195.33.23, my previous /etc/hosts entry was overriding it to 23.217.162.158 which was causing the certificate issue.

Thanks to everyone who responded.

[to...@tuxteam.de]

On Mon, Jan 03, 2022 at 11:01:34PM +0100, local10 wrote:

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

[local10]

Jan 4, 2022, 05:58 by to...@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

[to...@tuxteam.de]

Thanks, yes, I fllowed the thread :)

Cheers
--
t

[rhkr...@gmail.com]

On Tuesday, January 04, 2022 12:58:45 AM to...@tuxteam.de wrote:
> [1] Don't you hate GUIs? Describing how to do a simple thing ends up in
> reams of difficult-to-understand text.

+1 sometimes, but sometimes they offer a much easier way to do things with less
learning required -- there is a tradeoff (at least for some of us in some
cases) -- ease of use vs. ease of describing to someone else.

It would be nice if there was a simpler way to describe things -- maybe if all
GUI actions had a corresponding way to invoke from the CLI, and then the
description might start with the CLI command(s).

[to...@tuxteam.de]

Yes, it's a hard-to-solve equation :)

Cheers
--
t

[Michael Stone]

On Tue, Jan 04, 2022 at 01:09:06AM +0100, local10 wrote:
>> Jan 3, 2022, 23:08 by d...@randomstring.org:
>>> Alright. Put this into your /etc/hosts temporarily:

[...]

>OK, I understand now what the problem was. Quite a while ago I added a line into the /etc/hosts to fix a temp DNS issue and completely forgot about it. So while DNS server was correctly resolving tools.usps.com to 152.195.33.23, my previous /etc/hosts entry was overriding it to 23.217.162.158 which was causing the certificate issue.

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

[James H. H. Lampert]

On 1/4/22 10:19 AM, Michael Stone wrote:
> And this is why putting stuff into /etc/hosts is basically never the
> right answer. :)

Au contraire!

Among other things, the host table is the best possible place to block
access to certain unwanted domains. For example, if you add these entries:

> 0.0.0.0 facebook.com
> 0.0.0.0 www.facebook.com
> 0.0.0.0 hi-in.facebook.com
> 0.0.0.0 gl-es.facebook.com
> 0.0.0.0 twitter.com
> 0.0.0.0 www.twitter.com

you can never be tricked into accessing Facebook or Twitter (for me,
ONCE is far too many times), and if you add

> 0.0.0.0 bing.com

then bing-redirections will fail every time (and alert you to their
noisome and all-too-common presence).

And likewise, you might want to access other machines within your LAN by
name, but your operation is not big enough to warrant bothering with an
internal DNS, or you might need to access outside systems that, for
various perfectly legitimate reasons, are kept off the public DNS.

--
JHHL

[to...@tuxteam.de]

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 :)

Cheers
--
t

[to...@tuxteam.de]

On Tue, Jan 04, 2022 at 10:34:48AM -0800, James H. H. Lampert wrote:
> On 1/4/22 10:19 AM, Michael Stone wrote:
> > And this is why putting stuff into /etc/hosts is basically never the
> > right answer. :)
>
> Au contraire!
>
> Among other things, the host table is the best possible place to block
> access to certain unwanted domains. For example, if you add these entries:
>
> > 0.0.0.0 facebook.com

[...]

Oh, great minds think alike :)

I put them to 127.0.0.1, because then I can see them hitting the wall in
my local web server logs ;-)

Cheers
--
t

[local10]

Jan 4, 2022, 18:19 by mst...@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,

[David Wright]

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.

Cheers,
David.

[to...@tuxteam.de]

No idea. I'd hope for it to be overridable, but I've been disappointed
by browsers (yes, firefox, I'm looking at you!) before.

The day it ain't a choice anymore will be the day I hide behind a proxy
*I* trust and control. That one can then look up things in /etc/hosts.
(Yes, that means some bricolage with trusted root CAs. So be it.)

Cheers
--
t

[James H. H. Lampert]

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

[Michael Stone]

On Tue, Jan 04, 2022 at 10:34:48AM -0800, James H. H. Lampert wrote:

>On 1/4/22 10:19 AM, Michael Stone wrote:
>>And this is why putting stuff into /etc/hosts is basically never the
>>right answer. :)
>
>Au contraire!
>
>Among other things, the host table is the best possible place to block
>access to certain unwanted domains

Not really, but it certainly is something that people do.

[Celejar]

On Tue, 4 Jan 2022 20:58:27 +0100

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:

https://www.reddit.com/r/pihole/comments/rrcmfk/why_am_i_making_a_personal_commitment_to_donating/
https://www.reddit.com/r/pihole/comments/7rzdzj/how_many_domains_do_you_have_on_your_setup/
https://www.reddit.com/r/pihole/comments/hkfyu4/domains_on_blocklist/

etc.

and using DoH with Pi-hole is well documented:

https://docs.pi-hole.net/guides/dns/cloudflared/
https://medium.com/codex/pi-hole-and-doh-f1a9f8acd0f7
https://github.com/devopsleigh/pihole

Celejar

[Dan Ritter]

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-

[to...@tuxteam.de]

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).

But hey, full HTTP(S) proxying would be a great thing to do. Still,
you'd have to munge your browser's trusted certs for that trick to work.

Cheers
--
t

[to...@tuxteam.de]

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

[Dan Ritter]

to...@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-

[Celejar]

On Wed, 5 Jan 2022 06:10:48 +0100
<to...@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? If you mean that the
queries won't be secure during the leg between the client and
the Pi-hole, we're talking about running Pi-hole within one's trusted
network (or connecting to it over a VPN, etc.)

>
> But hey, full HTTP(S) proxying would be a great thing to do. Still,
> you'd have to munge your browser's trusted certs for that trick to work.

Celejar

[to...@tuxteam.de]

On Wed, Jan 05, 2022 at 08:43:23AM -0500, Celejar wrote:
> On Wed, 5 Jan 2022 06:10:48 +0100
> <to...@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.

Cheers
--
t

[Celejar]

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

[to...@tuxteam.de]

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

[Celejar]

On Wed, 5 Jan 2022 19:42:33 +0100
<to...@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