Its not that SETI doesn't use port 80, its that it also uses port 443 and he doesn't like that.

Any idea when it uses 443?

Normally, port 443 would be for encrypted (SSL/TLS) connections, with port 80 for straight, unencrypted HTTP connections.

So, I suspended network activity earlier today.

Tonight, when things were quiet, I told my router to log (in detail) all traffic in and out of my workstation, and told BOINC it could now talk to the world.

It uploaded a result, reported work, and requested new work.

All of the connections were to port 80 at the Berkeley end, and typical random ports (client ports) on my end.

Not sure why they'd use port 443 for anything, except maybe as a fall-back.

If port 80 is blocked, it sure isn't at Berkeley.

---

I thought that the standard BOINC and the vast majority of projects use http on port 80, but that WCG uses https on 443.

Given the level of advice in this thread about how to sort the problems out. I've come to a conclusions.

The user is using the machines without the Governments knowledge. Why else would he protest so much that he can't change the time of the connection to the severs. If his bosses knew that the computers in the office were used for Seti, they wouldn't care what time the connections happened. Also, only running them at 30% CPU time, just enough to get the units done, but not enough to be any sort of drag on the system.

The main point that draws me to this, is his sheer stubborn attitude that Seti is to blame.

When anyone who follows the project so avidly as he claims would know that the guys have nothing to work with and get sweet f a in return for all of their efforts.

---

I thought that the standard BOINC and the vast majority of projects use http on port 80, but that WCG uses https on 443.

.... and since this user is complaining about SETI and BOINC, and not WCG, that wouldn't be the reason.

Lots of different "things" use standard HTTP, and HTML-like or XML-like protocols because virtually every firewall is configured in some way to allow HTTP (while blocking dangerous or unknown protocols).

Usually so the less-sophisticated user can use whatever gadgets without having to configure their firewall to allow it.

The packet logging I did (43 megabytes of ASCII-hex) shows only port 80, and all of it talking to Apache servers at Berkeley.

---

I thought that the standard BOINC and the vast majority of projects use http on port 80, but that WCG uses https on 443.

.... and since this user is complaining about SETI and BOINC, and not WCG, that wouldn't be the reason.

Precisely. But the OP (most recent post) said:

Because the close of port 80 by seti...

No, marsinph. It wasn't closed by SETI. You'll need to look closer to home (or closer to office) to find out who closed it.

I thought that the standard BOINC and the vast majority of projects use http on port 80, but that WCG uses https on 443.

.... and since this user is complaining about SETI and BOINC, and not WCG, that wouldn't be the reason.

Precisely. But the OP (most recent post) said:

Because the close of port 80 by seti...

No, marsinph. It wasn't closed by SETI. You'll need to look closer to home (or closer to office) to find out who closed it.

... and not to put too fine a point on it, if SETI or BOINC used anything other than port 80, I would have seen it in the data stream. I'll also note that all of the connections were outbound, from the BOINC client to Berkeley, and not the other way 'round.

---

I thought that the standard BOINC and the vast majority of projects use http on port 80, but that WCG uses https on 443.

Thanks for pointing that out. I was under the impression that most projects were using secure communications via port 443, but I guess that's not true.

Then I don't see what the problem is. Port 80 should be open on most corporate networks for basic web browsing, unless they've secured their network and don't want their employees browsing the web during work hours.

One thing is for certain, SETI did not close port 80 to their servers, so it must be on Marsinph's end.

The security managment can not open permanently one port because hackers can come inside. It is the only reason.

...and they can't in you 2hr window???

Ask your firewall admin to put in a policy that permanently allows outgoing contact only to the project servers. All those got static (and known) IPs.
That's only two or three /29 networks and makes it much more secure than your weekly timeframe for all of port 80, because it's very unlikely that the project servers get hijacked...

---

mic.

The security managment can not open permanently one port because hackers can come inside. It is the only reason.

...and they can't in you 2hr window???

Ask your firewall admin to put in a policy that permanently allows outgoing contact only to the project servers. All those got static (and known) IPs.
That's only two or three /29 networks and makes it much more secure than your weekly timeframe for all of port 80, because it's very unlikely that the project servers get hijacked...

A good firewall is a perfect one-way mirror -- outbound connections can go out, but hackers can't come inside. They have to trick someone inside to bring the proverbial trojan horse into the city.

The BOINC client does not accept inbound connections from Berkeley or anyplace else.

Yet another reason to believe that this isn't exactly "authorized" use of the Ministry's computers.

---

A good firewall is a perfect one-way mirror -- outbound connections can go out, but hackers can't come inside. They have to trick someone inside to bring the proverbial trojan horse into the city.

And it's so easy - just make someone inside click a link...

The BOINC client does not accept inbound connections from Berkeley or anyplace else.

The BOINC client does accept inbound connections on port 31418 if you have a remote_hosts.cfg installed.
You will need that to manage 200 rigs...

---

mic.

The BOINC client does accept inbound connections on port 31418 if you have a remote_hosts.cfg installed.
You will need that to manage 200 rigs...

That would be port 31416.

But for 'management', assuming you're an authorised person within the Ministry, that would be a LAN-only function - no need for a hole in the perimeter firewall.

Arghh... Typo.

---

mic.

The BOINC client does accept inbound connections on port 31418 if you have a remote_hosts.cfg installed.
You will need that to manage 200 rigs...

... but, presumably, not from outside the Ministry. I don't know if they have internal firewalls or not -- or even how much one needs to "manage" that many machines.

---