disable "not private connection"

The "not private connection" is what shows up in Chrome. Firefox
has the same(?) thing by claiming a unsecured connection.

When I use google search: "usno time check" & the USNO Master Clock
item shows up, I selected the site; the responses above are what
happens.

The next item for USNO Observatory has the same problem.

Now, the USN uses "unsecured" web sites???

I just wanted to enter the correct time for my new phone
by calling also to check for a working phone, at least for calls!

Finally got a phone number by going down thru the list & got
one the response saying my phone's date & time has been set.

"Security" gone overboard!.

lew wrote:

The "not private connection" is what shows up in Chrome. Firefox
has the same(?) thing by claiming a unsecured connection.

When I use google search: "usno time check" & the USNO Master Clock
item shows up, I selected the site; the responses above are what
happens.

The next item for USNO Observatory has the same problem.

Now, the USN uses "unsecured" web sites???

What I see in Google Chrome 71 is:

https://imgur.com/a/6TALBpX

You did not cite the error code, which is:

NET::ERR_CERT_AUTHORITY_INVALID

That is saying the CA (certificate authority) for the cert is not
recognized. When I clicked anywhere in the page, more info shows up,
like when the cert expires. It hasn't expired yet, so there is some
other problem with their certificate. In the address bar, I clicked on
the "Not Secure" handle that shows a drop-list of further actions. I
clicked on "Certificate" to get more info. Under the Certification Path
tab, the chain goes back to the DOD as the CA.

If the web browser cannot contact the CA's server to check the
authenticity of a cert, it cannot decide if the cert is still okay. The
expiration date is what is encoded in the cert, but the cert might've
been revoked or expired at the CA. With OSCP (Online Certificate Status
Protocol), the client would ask the CA server to qualify the cert. The
CA server does the work. With the old method of using CRLs (certificate
revocation lists), the client has to get a list from the CA server of
revoked certs to check if the site's cert is on the blacklist (similar
to how stores used to get blacklists of bad checks to know which ones to
reject at the cash register). The client does the work.

The General tab on the cert's properties says "This certificate cannot
be verified up to a trusted certification authority". Doesn't mean the
cert is bad, only that the client cannot connect to the CA server to
verify the cert is still valid. Under the Details tab when I look at
the CRL Distribution Points attribute of the cert, it points to
http://crl.disa.mil/crl/DODIDSWCA_38.crl as the CRL on that CA's server.
When I "ping crl.disa.mil", it finds the host. "nslookup crl.disa.mil"
also works okay to report the IP address(s). Humans like names,
computers demand numbers, hence the need for DNS lookups (hostname to IP
address). So the host is reachable (from me) but that doesn't mean its
server program is responding to CRL requests.

The above was to see if I could reach their CRL server. Looks like I
can reach the host but don't know if their CRL server is responsive. I
then tried to "ping ocsp.disa.mil" for their OSCP server. It got the IP
address (so the DNS lookup succeeded) but the ping timeout. That could
mean their OSCP server is unresponsive, their host is down, it is
powered off, or they disabled ping.

When I run the site through SSLlabs to test their site certificate:

https://www.ssllabs.com/ssltest/anal...avy.mil&latest

it reports their certificate is not trusted. Of particular interest is
in the "#2 section" which says:

DoD Root CA 3 - Not in trusted store

Well, if the CA for a cert is not listed as trusted, any certs claiming
to be registered by that CA will be invalid. Another comment in that
section is:

DoD Root CA 3 - Self-signed

Self-signed certs are only for internal use. They cannot be trusted
outside the organization that generates them. SSLlabs, by comparison,
shows mozilla.org's cert is not self-signed. When programs (anti-virus,
stream capture, company proxies) want to use their self-signed cert, it
has to get added to the cert store used by the web client. That won't
happen outside of the organization that generated their own cert unless
you install programs that add them. There are problems with the navy
site's cert.

https://www.sslshopper.com/ssl-check....usno.navy.mil

That shows there is a problem in the chaining of certs. If you look at
the issuer of each intermediate or chained cert, the last one was issue
by DoD Root CA 3 which is the issue of the 2nd chained cert. Maybe that
has to do with using a self-signed cert.

Google Chrome uses the global certificate store managed by Windows (run
certmgr.msc to see them). Firefox uses their own private cert store. I
look in certmgr.msc but didn't see any Trusted Root CAs that had "DoD"
in their name.

https://www.cpms.osd.mil/Subpage/DODRootCertificates/

Could be you're not supposed to be using their internal sites. The
article describes how to install their self-signed root cert but I
didn't bother to figure it out. If they aren't currently listed as a
Trusted Root CA in my global cert store or Firefox's private cert store,
and unless they are used for MITM (man-in-the-middle) certs by local
programs that I install (streamed video capture from HTTPs sites,
anti-virus to let it interrogate HTTPS traffic), I'm not installing it.

After all, use of their atomic clock is restricted. They are a tier 1
NTP (network time protocol) provider, and end users don't get to access
those. If you were using one of their own computers where their sysprep
image already had their self-signed cert added to the global cert store
for the OS and Mozilla's private cert store in Firefox then you'd have
the root cert to validate their site cert.

https://www.endruntechnologies.com/stratum1.htm

The nearby university to which I sync my clock is a stratum 2 NTP
server. Sometimes that level requires permission to use. They allow
access unless you are abusive with how often you query their server.
time.nist.gov is one of the choices in Windows. While NIST operates
stratum-1 NTP server, I don't know if that's to what you get to connect.

I just wanted to enter the correct time for my new phone
by calling also to check for a working phone, at least for calls!

Finally got a phone number by going down thru the list & got
one the response saying my phone's date & time has been set.

"Security" gone overboard!.

Your phone will get its time from the cellular tower. I have no idea
how far they are in the stratum hierarchy but I doubt its strata 1 or 2.

https://android.gadgethacks.com/how-...clock-0170500/
"For most Android phones, the system clock is set using a protocol
called NITZ, which relies on a connection with your carrier to ensure
that the time stays in sync. The trouble here is that this feature won't
work when you're outside of cellular range, and a lot of times, the
carriers themselves have technical difficulties that can result in your
phone's clock being minutes or even hours out of sync."

Unless you plan on being out of range of all cell towers for a long
time, the drift in the cell phone's clock logic isn't important. The
atomic clock sync app they suggest requires you have an Internet
connection to perform the NTP lookup, so you have to be close to a wi-fi
hotspot or use data to a cell tower - and that means your phone would
sync to the cell tower's clock which makes the app superfluous.

In the Android settings (you didn't mention which OS on your phone),
under Date & Time, you can elect automatic sync. That syncs to the cell
tower's clock. Obviously you need a bar for signal strength to reach
the cell tower.

On 2018-12-11, VanguardLH wrote:
lew wrote:

The "not private connection" is what shows up in Chrome. Firefox
has the same(?) thing by claiming a unsecured connection.

When I use google search: "usno time check" & the USNO Master Clock
item shows up, I selected the site; the responses above are what
happens.

The next item for USNO Observatory has the same problem.

Now, the USN uses "unsecured" web sites???

What I see in Google Chrome 71 is:

https://imgur.com/a/6TALBpX

You did not cite the error code, which is:

NET::ERR_CERT_AUTHORITY_INVALID

That is saying the CA (certificate authority) for the cert is not
recognized. When I clicked anywhere in the page, more info shows up,
like when the cert expires. It hasn't expired yet, so there is some
other problem with their certificate. In the address bar, I clicked on
the "Not Secure" handle that shows a drop-list of further actions. I
clicked on "Certificate" to get more info. Under the Certification Path
tab, the chain goes back to the DOD as the CA.

If the web browser cannot contact the CA's server to check the
authenticity of a cert, it cannot decide if the cert is still okay. The
expiration date is what is encoded in the cert, but the cert might've
been revoked or expired at the CA. With OSCP (Online Certificate Status
Protocol), the client would ask the CA server to qualify the cert. The
CA server does the work. With the old method of using CRLs (certificate
revocation lists), the client has to get a list from the CA server of
revoked certs to check if the site's cert is on the blacklist (similar
to how stores used to get blacklists of bad checks to know which ones to
reject at the cash register). The client does the work.

The General tab on the cert's properties says "This certificate cannot
be verified up to a trusted certification authority". Doesn't mean the
cert is bad, only that the client cannot connect to the CA server to
verify the cert is still valid. Under the Details tab when I look at
the CRL Distribution Points attribute of the cert, it points to
http://crl.disa.mil/crl/DODIDSWCA_38.crl as the CRL on that CA's server.
When I "ping crl.disa.mil", it finds the host. "nslookup crl.disa.mil"
also works okay to report the IP address(s). Humans like names,
computers demand numbers, hence the need for DNS lookups (hostname to IP
address). So the host is reachable (from me) but that doesn't mean its
server program is responding to CRL requests.

The above was to see if I could reach their CRL server. Looks like I
can reach the host but don't know if their CRL server is responsive. I
then tried to "ping ocsp.disa.mil" for their OSCP server. It got the IP
address (so the DNS lookup succeeded) but the ping timeout. That could
mean their OSCP server is unresponsive, their host is down, it is
powered off, or they disabled ping.

When I run the site through SSLlabs to test their site certificate:

https://www.ssllabs.com/ssltest/anal...avy.mil&latest

it reports their certificate is not trusted. Of particular interest is
in the "#2 section" which says:

DoD Root CA 3 - Not in trusted store

Well, if the CA for a cert is not listed as trusted, any certs claiming
to be registered by that CA will be invalid. Another comment in that
section is:

DoD Root CA 3 - Self-signed

Self-signed certs are only for internal use. They cannot be trusted
outside the organization that generates them. SSLlabs, by comparison,
shows mozilla.org's cert is not self-signed. When programs (anti-virus,
stream capture, company proxies) want to use their self-signed cert, it
has to get added to the cert store used by the web client. That won't
happen outside of the organization that generated their own cert unless
you install programs that add them. There are problems with the navy
site's cert.

https://www.sslshopper.com/ssl-check....usno.navy.mil

That shows there is a problem in the chaining of certs. If you look at
the issuer of each intermediate or chained cert, the last one was issue
by DoD Root CA 3 which is the issue of the 2nd chained cert. Maybe that
has to do with using a self-signed cert.

Google Chrome uses the global certificate store managed by Windows (run
certmgr.msc to see them). Firefox uses their own private cert store. I
look in certmgr.msc but didn't see any Trusted Root CAs that had "DoD"
in their name.

https://www.cpms.osd.mil/Subpage/DODRootCertificates/

Could be you're not supposed to be using their internal sites. The
article describes how to install their self-signed root cert but I
didn't bother to figure it out. If they aren't currently listed as a
Trusted Root CA in my global cert store or Firefox's private cert store,
and unless they are used for MITM (man-in-the-middle) certs by local
programs that I install (streamed video capture from HTTPs sites,
anti-virus to let it interrogate HTTPS traffic), I'm not installing it.

After all, use of their atomic clock is restricted. They are a tier 1
NTP (network time protocol) provider, and end users don't get to access
those. If you were using one of their own computers where their sysprep
image already had their self-signed cert added to the global cert store
for the OS and Mozilla's private cert store in Firefox then you'd have
the root cert to validate their site cert.

https://www.endruntechnologies.com/stratum1.htm

The nearby university to which I sync my clock is a stratum 2 NTP
server. Sometimes that level requires permission to use. They allow
access unless you are abusive with how often you query their server.
time.nist.gov is one of the choices in Windows. While NIST operates
stratum-1 NTP server, I don't know if that's to what you get to connect.

I just wanted to enter the correct time for my new phone
by calling also to check for a working phone, at least for calls!

Finally got a phone number by going down thru the list & got
one the response saying my phone's date & time has been set.

"Security" gone overboard!.

Your phone will get its time from the cellular tower. I have no idea
how far they are in the stratum hierarchy but I doubt its strata 1 or 2.

https://android.gadgethacks.com/how-...clock-0170500/
"For most Android phones, the system clock is set using a protocol
called NITZ, which relies on a connection with your carrier to ensure
that the time stays in sync. The trouble here is that this feature won't
work when you're outside of cellular range, and a lot of times, the
carriers themselves have technical difficulties that can result in your
phone's clock being minutes or even hours out of sync."

Unless you plan on being out of range of all cell towers for a long
time, the drift in the cell phone's clock logic isn't important. The
atomic clock sync app they suggest requires you have an Internet
connection to perform the NTP lookup, so you have to be close to a wi-fi
hotspot or use data to a cell tower - and that means your phone would
sync to the cell tower's clock which makes the app superfluous.

In the Android settings (you didn't mention which OS on your phone),
under Date & Time, you can elect automatic sync. That syncs to the cell
tower's clock. Obviously you need a bar for signal strength to reach
the cell tower.

I did forgot to mention the most important item of all. The phone is
a landline phone that I just got because it had a "call block" button &
quick entry into the call block list. I don't have a cell phone. The
cliche that "everybody" has a cell phone is a major fraud.

Interestingly, my fax machine lit up (on the same line).

Still there should be some way to disable the site blocking on a temp
basis. When I sign on to my nas, I get a msg that the connection is
"unsecured", I think may be from the Synology login, but still get
me connected. I had tried my health plan's site for list of doctors,
the site is also "unsecured" & get blocked; I don't care if the
connection is "unsecured" for certain places if I am just getting
info from a know & trusted site no matter regardless of their
certificate situation.

On Mon, 10 Dec 2018 22:35:52 -0000 (UTC), lew wrote:

The "not private connection" is what shows up in Chrome. Firefox
has the same(?) thing by claiming a unsecured connection.

When I use google search: "usno time check" & the USNO Master Clock
item shows up, I selected the site; the responses above are what
happens.

The next item for USNO Observatory has the same problem.

Now, the USN uses "unsecured" web sites???

I just wanted to enter the correct time for my new phone


As a civilian, you should be using the civilian site at https://time.gov/.

The USN site is secured by a Department of Defense root certificate.
You do not have the Department of Defense root certificate in your
certificate store, presumably because you are not part of the
Department of Defense, and that is why you get this error.


--
Kind regards
Ralph

lew wrote:

I did forgot to mention the most important item of all. The phone is
a landline phone that I just got because it had a "call block" button
& quick entry into the call block list. I don't have a cell phone.
The cliche that "everybody" has a cell phone is a major fraud.

Then your landline phone has you set its clock. Use your computer's
clock to set your landline phone's clock. Your computer clock is
probably only milliseconds off from a statrum-1 NTP server; however,
there's no way you could get ready to tap the button on your landline
phone to sync with the computer's clock without incurring more than many
milliseconds.

It's possible for a clock or phone to get the time from the A/C power.
At 60 Hz (1/60 second/cycle), there should be 5,184,000 cycles per day:
60 seconds/minute * 60 minutes/hour * 24 hours/day * 60 cycles/second =
5,184,000 cycles. At some correction point, the total cycles in a day
may be more or less, so the cycles get shortened or lengthened a bit so
there are that many cycles in a 24-hour period or whenever the power
company decides an error threshold has been exceeded. 60Hz usually
floats around .02Hz off. You set the clock and it counts the cycles on
the power line to correct any drift in its time. One day it might be a
few [milli]seconds fast and the next it gets slowed, and another day it
could be a few [milli]seconds slow and the next its sped up. This is,
after all, how atomic sync tools work: you're off (high or low) by a few
milliseconds, so they correct the time. However, instead of simply
changing the clock value, AC power line clocking gets the cycles
squeezed or lengthened. How accurate your power-line clock stays
accurate depends on how the power company performs at their averaging of
cycles per day.

There are also "atomic clocks" you can buy that get the time from NIST
labs in Boulder, CO as long as the clock can get a decent shortwave
signal from their tower. I think it's the only one in the USA relying
on shortwave radio bouncing off the ionosphere to extend its range. I
had one in my basement but the signal was too weak for most syncs and
usually took way over an hour to correct its time (the icon showing sync
in progress kept blinking for longer than I was willing to watch the
clock do its sync).

I've yet had a landline phone that syncs to the powerline's cycle count
per day. I haven't had one that synchronized to Boulder, CO shortwave
signal, either. I've had to manually set the time, and if I'm off then
the phone remains that far off and perhaps even more as its clock
drifts. Since the answering machine within the landline phone doesn't
show seconds but only has a granualarity of a minute, there's no need to
be synchronizing down to the millisecond to an NTP server. Who cares if
someone called or left a message at 08:32.001 or 08:32.294? All the
phone is going to tell you is the call got logged or voicemail was left
at 08:32. Since you mentioned "phone" and time sync, and because I
haven't yet used a POTS phone that used shortwave or powerline to adjust
its time, I figured you must be asking about a cell phone. You watching
a time counter and trying to hit the button on your phone at the exact
instant the time changes to a minute boundary would be off by many
milliseconds, so I wasn't sure why you were looking at the atomic time.

Interestingly, my fax machine lit up (on the same line).

Still there should be some way to disable the site blocking on a temp
basis. When I sign on to my nas, I get a msg that the connection is
"unsecured", I think may be from the Synology login, but still get
me connected.

Because you are using HTTP to connect to the server internal in the NAS.
You aren't using HTTPS. Similarly, when I connect to the internal web
server in my cable modem's router, I'm using HTTP, not HTTPS. That host
doesn't need a secured connection on the LAN-side ports. It's your
property being used by your hosts. The web browser notifying you a
connection is not secure is, well, just telling you that it isn't secure
(via HTTPS). It's an informational comment, not something restricting
you from going there. Not all sites employ certificates to support
HTTPS connections. Not every site has logins. Not every site needs to
encrypt what is considered publicly accessible information to all
visitors. Not every site feels compelled to prove to you that you
reached the site you intended to reach. Such sites are becoming rare.

http://www.troubleshooters.com/codec...rl/perlreg.htm

That is a site that uses HTTP, not HTTPS. Their info is public. You
don't login there. They don't care to prove they are who you thought
you went. The web browser says "Not secure" but so what? A site does
not have to be secured unless there are reasons to do so.

I had tried my health plan's site for list of doctors,
the site is also "unsecured" & get blocked; I don't care if the
connection is "unsecured" for certain places if I am just getting
info from a know & trusted site no matter regardless of their
certificate situation.

Assuming the server you reached (connected to) is the one you specified
and not somewhere else due to, for example, DNS poisoning. Many sites
are going to HTTPS mostly to provide reasonable proof of who they are
(that you got to where you wanted). None of their information may be
private; i.e., none of it is sensitive and ALL of it is considered
public information. Many users are paranoid about their ISP or someone
else interrogating the content of their web traffic, even when they are
visiting HTTP sites, so that's another reason to use HTTPS. The site
can prove who they are (you can see their cert details) and they concede
to users that want privacy. HTTPS doesn't hide to where you connected
(you need a VPN or TOR for that), only the content the site delivered to
you.

HTTPS also simplifies logins. In the past when HTTP was prevalent, many
users didn't like visiting non-secured web page to enter their login
credentials. I remember Hotmail and many other sites were like that.
If you looked at what they were doing, they showed a form whose submit
action pointed at an HTTPS server. That meant the form data (for login
credentials) did *not* get sent as plain text in the clear but the page
connected to an HTTPS server to accept the login credentials. Yet users
don't typically understand HTML, so they wanted that secure icon in the
address bar showing the login page was secured.

lew wrote:

Firefox has the same(?) thing by claiming a unsecured connection.

Firefox and chrome are both correct, the Naval Observatory isn't willing
to spend a few dollars on a web server certificate.

In effect they're saying "we're the Navy because we say we are", if you
believe them you can click advanced and add an exception.