How should this system be protected from ARP spoofing?

Question

Background

My university uses an authenticated (squid) HTTP proxy server for accessing the internet.

There are a few reasons for this:

• They want to track misuse of the connection
• Our university has subscriptions to most paywalled journals, and logging in via the proxy server unlocks this. Outsiders and folks which tunnel¹ into the system should not be able to access these either.
• They want to make sure that we don't script-download a lot of stuff from the journal websites -- accountability is the best way to do that.
• They want to be able to block certain ports and sites. Aside from 80, 443 and 22, IIRC all the ports are blocked.

All logins on our institute are on ldap, as is the squid proxy. Which means that the same credentials are used for many other (more crucial) systems, and with them one could wreak havoc. For example, one can mess around with what courses people are going to take, drop people from courses, and cause many other problems.

The problem

The other day, while messing with ettercap, I discovered that it was quite easy to pipe it with grep and get proxy authorization data² (which is just a base64 encoded header) from all people using the internet in a subnet of my choosing.

I would like to bring this to the attention of the authorities, as it's a rather severe bug. I'd also like to devise a fix for it.

Now, it is easy to protect the online portals from ARP spoofing by making them HTTPS (still spoofable, but IIRC Chrome starts complaining). However, there doesn't seem to be a consistent (across browsers) way to make HTTP Proxy authorization secure (or a SOCKS proxy, for that matter).

A (not so good) solution

One solution is to use two sets of credentials -- one for the proxy and one for the rest of the intranet web portal logins (which can be made HTTPS). Keeping the proxy safe from impersonation isn't that big a deal. Someone tunneling in can't ARP spoof unless they already have access, and there are a few other checks in place that will make it hard to falsely implicate someone by misusing the proxy in their name (IP logging, etc). On the other hand, keeping the intranet web portal pages secure is priority, due to the amount of havoc that can be caused with the credentials.

However, this isn't optimum, as the proxy is still open to abuse (just harder to abuse it), and people reuse passwords.

TL;DR

How does one (with control over the network infrastructure) prevent ARP spoofing on proxy authentication? I'm open to replacing the proxy with a similar entity (it must have auth though).

^{1. While shell access requires a login on your respective department, tunneling in requires a publicly available password. I guess that's something that should be changed as well.}

^{2. This is easier than just logging generic POST requests and extracting passwords since there is a specific, grep-able format to this and the proxy credentials are sent with every GET and POST request one makes (which means that I can get a sizeable amount of data after running ettercap for just a minute.}

Answer 1

There is a possibility to encrypt the connection to the proxy, there was a question on this site.Please find the link mentioned below.However the methods mentioned may not work at all times.

Is it possible to connect to a proxy with an ssl (or otherwise encrypted) connection?

To answer your query regarding implementing this on the network infrastructure:

There is a feature called Dynamic Arp Inspection.This can be enabled on supported switches.Each ARP packet is looked into by the switch and the IP mac binding is verified with a Trusted binding table.(I believe that the binding table is populated by snooping into DHCP at the time of IP allocation and i guess static binding between IP and mac can also be configured on the table).So any ARP packet with an incorrect mapping between IP and ARP is dropped hence preventing poisoning.