'How many readers here use the 'news.myplugbox.com' newsgroups?

PING myplugbox.com (212.56.88.149) 56(84) bytes of data.
64 bytes from myplugbox.com (212.56.88.149): icmp_seq=1 ttl=45 time=94.9 ms
64 bytes from myplugbox.com (212.56.88.149): icmp_seq=2 ttl=45 time=95.0 ms
64 bytes from myplugbox.com (212.56.88.149): icmp_seq=3 ttl=45 time=95.3 ms
64 bytes from myplugbox.com (212.56.88.149): icmp_seq=4 ttl=45 time=95.0 ms
64 bytes from myplugbox.com (212.56.88.149): icmp_seq=5 ttl=45 time=104 ms

--- myplugbox.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4004ms
rtt min/avg/max/mdev = 94.999/97.047/104.889/3.927 ms


Looks much the same as THIS data:-


PING dogagent.com (212.56.88.149) 56(84) bytes of data.
64 bytes from myplugbox.com (212.56.88.149): icmp_seq=1 ttl=45 time=95.1 ms
64 bytes from myplugbox.com (212.56.88.149): icmp_seq=2 ttl=45 time=94.8 ms
64 bytes from myplugbox.com (212.56.88.149): icmp_seq=3 ttl=45 time=95.0 ms
64 bytes from myplugbox.com (212.56.88.149): icmp_seq=4 ttl=45 time=101 ms
64 bytes from myplugbox.com (212.56.88.149): icmp_seq=5 ttl=45 time=95.0 ms

--- dogagent.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4005ms
rtt min/avg/max/mdev = 94.834/96.410/101.975/2.811 ms


=

Is this *NORMAL*?

Connections to either www.dogagent.com OR to www.myplugbox.com are
shown by my various browsers as being *unsecure*.

https://imgur.com/UhA5AqV

Comments invited.

--
David B.

David B. wrote:
PING myplugbox.com (212.56.88.149) 56(84) bytes of data.
64 bytes from myplugbox.com (212.56.88.149): icmp_seq=1 ttl=45 time=94.9 ms

Is this *NORMAL*?

Connections to either www.dogagent.com OR to www.myplugbox.com are
shown by my various browsers as being *unsecure*.

The server only supports http on port 80.
It's not a surprise it's "unsecure", since using
https doesn't work at all.

Some servers, if you use http: they use https:
in some sort of redirection, forcing the browser
to make a secure connection. In a sense, the web server
in that case supports both, but only by providing
a "stub" for http: , just enough to redirect to https: .
That would be part of the world-wide "https everywhere"
campaign.

That server has none of that rubbish. It's a 1990's web
server and dedicated to the old way. Attempts to use
a newer protocol in the form of https: , simply don't work.

The ping is normal, in that the ping comes back.

BTW, the server and the information concerning it,
screams "private server, go away". The operator of the
server has made no attempt whatsoever to "promote it"
or invite joe lunchbox to join in. Thus, it's likely
to be a private invite, "I tell you the secret and
then you can use it" server. If you look at the
evidence, the server is constructed in a very peculiar
way, almost like a "honeypot". Like it's virtualized
and armed against silliness. Sorta like an iceburg.
It has a big part under the water line, and a tiny
part on the surface. And the tiny part on the surface
looks downright weird.

Unless the operator of the server has given you an
invite, I'd stay out if I were you. But of course
I'm not you.

The only references I can find to that server,
are *you* asking questions about it since around
2016 or so.

It's not a surprise to me, that it rejects your attempts
to connect. The "naive attack surface" of that node,
was obviously put there for people like you. Like
a "Welcome" mat on someones doorstep, with a
land mine underneath it.

I have absolutely no interest in probing that further.

It's like finding a turd in the water. Yes, it's
a turd. What's your next question ? Yes, it floats.
Now, what can we do with it ? Well, it's a turd.

I poked it, it rolled over in the water, and it's
still a turd. I'm not even curious. I've moved on.

Paul

On 30/01/2019 13:38, Paul wrote:
David B. wrote:
PING myplugbox.com (212.56.88.149) 56(84) bytes of data.
64 bytes from myplugbox.com (212.56.88.149): icmp_seq=1 ttl=45
time=94.9 ms

Is this *NORMAL*?

Connections to either www.dogagent.comÂ* OR to www.myplugbox.com are
shown by my various browsers as being *unsecure*.

The server only supports http on port 80.
It's not a surprise it's "unsecure", since using
https doesn't work at all.

Some servers, if you use http: they use https:
in some sort of redirection, forcing the browser
to make a secure connection. In a sense, the web server
in that case supports both, but only by providing
a "stub" for http: , just enough to redirect to https: .
That would be part of the world-wide "https everywhere"
campaign.

That server has none of that rubbish. It's a 1990's web
server and dedicated to the old way. Attempts to use
a newer protocol in the form of https: , simply don't work.

The ping is normal, in that the ping comes back.

BTW, the server and the information concerning it,
screams "private server, go away". The operator of the
server has made no attempt whatsoever to "promote it"
or invite joe lunchbox to join in. Thus, it's likely
to be a private invite, "I tell you the secret and
then you can use it" server. If you look at the
evidence, the server is constructed in a very peculiar
way, almost like a "honeypot". Like it's virtualized
and armed against silliness. Sorta like an iceburg.
It has a big part under the water line, and a tiny
part on the surface. And the tiny part on the surface
looks downright weird.

Unless the operator of the server has given you an
invite, I'd stay out if I were you. But of course
I'm not you.

The only references I can find to that server,
are *you* asking questions about it since around
2016 or so.

It's not a surprise to me, that it rejects your attempts
to connect. The "naive attack surface" of that node,
was obviously put there for people like you. Like
a "Welcome" mat on someones doorstep, with a
land mine underneath it.

I have absolutely no interest in probing that further.

It's like finding a turd in the water. Yes, it's
a turd. What's your next question ? Yes, it floats.
Now, what can we do with it ? Well, it's a turd.

I poked it, it rolled over in the water, and it's
still a turd. I'm not even curious. I've moved on.

Â*Â* Paul

I've read your words with great interest, Paul. Thank you. :-)

I'll wait to see if the 'moderator' of the User2User group there chips
in with his personal viewpoint.

You may have seen him post here in THIS group from time to time:-

...w¡ñ§±¤ñ
msft mvp windows experience 2007-2016, insider mvp 2016-2018

--
David B.

David B. wrote:


I'll wait to see if the 'moderator' of the User2User group there chips
in with his personal viewpoint.

Computers can be connected directly to the Internet.

They can run multiple serving functions (HTTP, NNTP).

They can also support more than domain name.

A server for which the user wants people to join, will
have a "welcome" page on the HTTP server. That's not
present on this server, so it doesn't appear to be intended
for direct usage by just anyone.

If the setup is "packaged" in some way, for usage with
some other machine, that wouldn't surprise me.

Paul

On Wed, 30 Jan 2019 08:38:33 -0500, Paul wrote:

Some servers, if you use http: they use https:
in some sort of redirection, forcing the browser
to make a secure connection. In a sense, the web server
in that case supports both, but only by providing
a "stub" for http: , just enough to redirect to https: .
That would be part of the world-wide "https everywhere"
campaign.

That's called an HTTP Redirect, and within the last 10 years or so it's
almost never done by the actual web server. Instead, it'll almost always
be done by a load balancer before the request ever makes it to a web
server, although the user would be unaware of the difference. Look for
HTTP Response codes of 301 (Moved Permanently) or 302 (Found, previously
referred to as Moved Temporarily), as well as other 30x codes. In all
cases, web clients know that when they see a 30x response code, they
need to look for a Location header and retry the request using the
address listed there.
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes

Here's a random example that shows a HTTP-to-HTTPS redirect:

curl -v www.cnn.com
* About to connect() to www.cnn.com port 80 (#0)
* Trying 151.101.1.67... connected
* Connected to www.cnn.com (151.101.1.67) port 80 (#0)
GET / HTTP/1.1
User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7
OpenSSL/1.0.1l zlib/1.2.3 libidn/1.18
Host: www.cnn.com
Accept: */*

HTTP/1.1 301 Moved Permanently
Server: Varnish
Retry-After: 0
Content-Length: 0
Cache-Control: public, max-age=600
Location: https://www.cnn.com/
Accept-Ranges: bytes
Date: Wed, 30 Jan 2019 17:14:57 GMT
Via: 1.1 varnish
Connection: close
Set-Cookie: countryCode=US; Domain=.cnn.com; Path=/
Set-Cookie: geoData=city, state, zip|US|NA; Domain=.cnn.com;
X-Served-By: cache-iah17244-IAH
X-Cache: HIT
X-Cache-Hits: 0

* Closing connection #0

The first line is the curl command that I ran. After that, the 'right
arrows' show information that was sent with the request, while the 'left
arrows' show information that was returned by "the server" (although in
the case of CNN this request never actually made it through to one of
their web servers. It was answered by a load balancer. DAMHIK)

We see that the HTTP response code was "301 Moved Permanently", rather
than the expected "200 OK", so we know it's going to be a redirect, but
redirect to where? To answer that, we check the Location header returned
in the response and we see that we're being redirected to
"https://www.cnn.com/". Note that a redirect can be to *anywhere*. It
doesn't have to be the https version of the site that was initially
requested. It doesn't even have to be a site at the same domain. The
protocol in the target of the Location header can be any protocol that
web browsers are expected to know, including http, https, ftp, etc.

Also note that the actual request has a trailing slash, which is
required. As users, we almost never include the trailing slash in our
web requests, but it's required, so every web browser knows it needs to
check to see if it was included and tack it on if it was missing. In
this case, curl tacked it on for me, which you can see in the "GET /
HTTP/1/1" line. The slash by itself simply tells the web server to send
its default document.

Funny story: At one customer site a few years ago, the network engineers
wanted to play a prank on their boss, a die hard fan of a specific
sports team. They asked me to configure a redirect rule on their load
balancer so that every time their boss requested any URL at his favorite
team's web site, he would instead get the home page from their biggest
rival. Of course, they wanted the rule to apply only to him, so that
when he came to their office to ask WTH is going on, they could show him
that everything is working properly. The prank worked perfectly and
everyone had a good laugh. Before I left the site, they asked me to
disable the rule but not to delete it. They clearly had some ideas on
ways to use variants in the future.

On Wed, 30 Jan 2019 15:05:08 +0000, David B. wrote:

I'll wait to see if the 'moderator' of the User2User group there chips
in with his personal viewpoint.
You may have seen him post here in THIS group from time to time:-
...w¡ñ§±¤ñ
msft mvp windows experience 2007-2016, insider mvp 2016-2018

like a dog with a bone
--
A stupid man's report of what a clever man says can never be accurate,
because he unconsciously translates what he hears into something he
can understand. -Bertrand Russell
Registered Linux User #393236

On Thu, 31 Jan 2019 10:14:32 +0000, Owner wrote:

On 30/01/2019 18:14, Char Jackson wrote:
On Wed, 30 Jan 2019 08:38:33 -0500, Paul wrote:

Some servers, if you use http: they use https:
in some sort of redirection, forcing the browser
to make a secure connection. In a sense, the web server
in that case supports both, but only by providing
a "stub" for http: , just enough to redirect to https: .
That would be part of the world-wide "https everywhere"
campaign.

That's called an HTTP Redirect, and within the last 10 years or so it's
almost never done by the actual web server. Instead, it'll almost always
be done by a load balancer before the request ever makes it to a web
server, although the user would be unaware of the difference. Look for
HTTP Response codes of 301 (Moved Permanently) or 302 (Found, previously
referred to as Moved Temporarily), as well as other 30x codes. In all
cases, web clients know that when they see a 30x response code, they
need to look for a Location header and retry the request using the
address listed there.
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
SNIPED for brevity

Most interesting - but I'm sure we'd all like to know the result you got
from your review of the actual rogue www.mypugbox.com

Please share!

Who's asking? David, is that you with yet another nym?

On 2019-01-31 14:19, Char Jackson wrote:
On Thu, 31 Jan 2019 10:14:32 +0000, Owner wrote:

On 30/01/2019 18:14, Char Jackson wrote:
On Wed, 30 Jan 2019 08:38:33 -0500, Paul wrote:

Some servers, if you use http: they use https:
in some sort of redirection, forcing the browser
to make a secure connection. In a sense, the web server
in that case supports both, but only by providing
a "stub" for http: , just enough to redirect to https: .
That would be part of the world-wide "https everywhere"
campaign.

That's called an HTTP Redirect, and within the last 10 years or so it's
almost never done by the actual web server. Instead, it'll almost always
be done by a load balancer before the request ever makes it to a web
server, although the user would be unaware of the difference. Look for
HTTP Response codes of 301 (Moved Permanently) or 302 (Found, previously
referred to as Moved Temporarily), as well as other 30x codes. In all
cases, web clients know that when they see a 30x response code, they
need to look for a Location header and retry the request using the
address listed there.
https://en.wikipedia.org/wiki/List_of_HTTP_status_codes
SNIPED for brevity

Most interesting - but I'm sure we'd all like to know the result you got
from your review of the actual rogue www.mypugbox.com

Please share!

Who's asking? David, is that you with yet another nym?


That is almost certainly another David B. nym.