Notified: April 23, 2002 Updated: May 23, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Updated: September 23, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: June 20, 2002
Not Affected
In relation to this CERT vulnerability note on security vulnerabilities with HTTP CONNECT, Alcatel has conducted an immediate assessment to determine any impact this may have on our portfolio. A first analysis has shown that none of our products which embed an HTTP proxy is affected when used as delivered to customers. Customers may contact their Alcatel support representative for more details. The security of our customers' networks is of highest priority for Alcatel. Therefore we continue to test our product portfolio against potential HTTP CONNECT security vulnerabilities and will provide updates if necessary.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC does not have information about the default configurations of Alcatel devices that implement HTTP proxy services.
Updated: September 23, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
AnalogX Proxy 4.14 (May 2003) blocks connections to port 25/tcp by default and provides access control for destination ports used by the HTTP CONNECT method. A warning is displayed if the proxy is configured to listen on all IP addresses, and the proxy can be bound to one address.
Notified: April 19, 2002 Updated: October 16, 2002
Not Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The Apache HTTP Server listens on all IP interfaces by default. The documentation for the Apache mod_proxy module states: "By default, only the default https port (443) and the default snews port (563) are enabled." Individual vendors may configure Apache differently.
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Updated: June 19, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Updated: September 15, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
In a message posted to BugTraq (BID 4143), Steve VanDevender reports that this vulnerability has been exploited in CacheFlow products to relay spam. In this message to the Incidents mailing list, Tim Kennedy provides a more secure CacheFlow configuration.
Updated: April 19, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
CERN httpd (W3C httpd) has not been maintained since 1996. The CERN httpd does not appear to support the HTTP CONNECT method.
Updated: September 23, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: July 23, 2002
Not Affected
The most recent versions of VPN-1/FireWall-1, versions NG FP2 and 4.1 SP6, are in no way vulnerable to the HTTP Connect vulnerability described below. In addition, even in previous versions, Check Point's products did not allow "arbitrary connections"; in fact, no connections were possible unless an explicit rule existed in the rule base allowing a specific connection from the original source IP to the eventual destination IP. No escalation of privilege was granted. No bypass of HTTP content or anti-virus scanning was possible. The only exposure, per se, was that the outbound connection from the firewall would have the firewall's source IP address when seen by the eventual target. The simple workaround for this issue, in older product versions, was to simply have a rule on the firewall which blocks connections which come from an external IP address and are destined to an external IP address. Since connections established by the HTTP Connect method must still be validated by the rulebase, this solution (a good idea, in any case) would prevent an external hacker from "bouncing" connections through the firewall to another external system. New versions of VPN-1/FireWall-1 offer the administrator more granular control over the use of HTTP Connect. Check Point's posted response to this issue as originally published is available at http://www.checkpoint.com/techsupport/alerts/http_connect.html.
The vendor has not provided us with any further information regarding this vulnerability.
In a message posted to bugtraq (BID 4131), Volker Tanger reports that this vulnerability could allow an arbitrary TCP connection to be made through FireWall-1 4.1 SP5. Based on further public discussion and information from Check Point, it seems that while the FireWall-1 HTTP proxy service may allow arbitrary HTTP CONNECT method connections, such connections are denied unless explicitly permitted in the firewall rule base.
Notified: April 19, 2002 Updated: May 16, 2002
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Cisco has released a Cisco Security Advisory addressing this vulnerability (CSCdx05705).
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Updated: June 29, 2004
Not Affected
When DeleGate is running as a HTTP proxy server, it allows only port 443 and 564 as the destination port of the CONNECT method, by default. When DeleGate relays a request with a header, it removes malformed header fields like "RCPT To:..." for example (illegal space in this case). And when DeleGate is relaying to a non-HTTP but privileged port, it tries to detect greeting message from non-HTTP server before relaying a request to it. If the server returns non-HTTP response like "220 ready" within a specified time period, then the request is rejected without forwarded to the server. These mechanisms have been available since 1999 (after DeleGate version 6).
The vendor has not provided us with any further information regarding this vulnerability.
Please see the Access control section of the DeleGate manual.
Updated: May 24, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Eolian went out of business in 2000. The vulnerability status of their InfoStorm product is unknown.
Notified: April 19, 2002 Updated: May 28, 2002
Not Affected
F5 Networks' EDGE-FX Cache product permits CONNECT requests only to ports 443, 8443, 8081, and 563 by default.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Updated: April 12, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: May 29, 2002
Not Affected
[HP does not] have any products with insecure default configurations in HTTP proxy services.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: September 23, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
It has been reported that IBM Web Traffic Express (WTE)/WebSphere EdgeServer ships with an insecure HTTP proxy configuration.
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: May 13, 2002 Updated: May 23, 2002
Not Affected
Inktomi Traffic Server allows CONNECT tunnels only to a list of specifically allowed target ports. CONNECT requests to any other port will be denied. The allowed port list can be read or updated from the "Protocols" page of the administrative GUI, or by editting the proxy .config.http.ssl_ports variable in the master configuration file. The only ports allowed by default are port 443 and port 563. Traffic Server blocks recursive service requests.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: May 18, 2002 Updated: May 29, 2002
Not Affected
Our products do not provide HTTP services, so there is no impact for us.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Updated: February 10, 2003
Not Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The default configuration of Internet Junkbuster 2.0.2 only blocks access to port 23/tcp, but also only listens to the loopback interface (127.0.0.1). Access to other TCP ports can be restricted as specified in the Internet Junkbuster FAQ. Previous versions of Junkbuster may by default listen on all interfaces (INADDR ANY) without an adequate ACL.
Updated: October 15, 2002
Affected
WinRoute Pro customers are in 99% of cases using NAT for Internet access, therefore making it impossible to connect to the proxy server through external interfaces and thus exploit CONNECT method. Cusomers that are not using NAT but are using (or have enabled) the proxy component, should create appropriate packet filtering rules. The reasonable rule would be to filter incoming external TCP traffic on port 3128, where by default the proxy server listens.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: May 29, 2002
Not Affected
Lotus products are not vulnerable. [Lotus does] not provide proxy services.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: May 29, 2002
Not Affected
Neither MultiNet nor TCPware include an HTTP server or HTTP proxy services.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Updated: June 29, 2004
Not Affected
SAFEBORDER (SSL VPN appliance) - is NOT vulnerable. Although it works as a SOCKS proxy service, it allows no TCP/UDP connection with its default configuration.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: June 19, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Please see the "Proxy used for spam" thread in novell.support.internet.bordermanager.proxies-fastcache.
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 23, 2002 Updated: May 29, 2002
Not Affected
Our proxy services and HTTP proxies are not vulnerable.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Updated: May 23, 2002
Not Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The default configuration of RabbIT limits HTTP CONNECT method connections to ports 443/TCP, 444/TCP, and 445/TCP.
Updated: September 23, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Updated: September 23, 2003
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Updated: October 16, 2002
Not Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
By default, Squid allows access to a limited number of privileged ports and all non-privileged ports, as noted in the Squid Access Controls FAQ. Squid also denies all client requests by default, as noted in the Squid Security Concerns FAQ. Individual vendors may configure Squid differently.
Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: June 19, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Updated: June 25, 2002
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Updated: April 16, 2002
Not Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The TIS Firewall Toolkit (FWTK) 2.x supports HTTP tunneling via the http-gw and/or plug-gw modules. Also, an older SSL proxy module (ssl-gw) is available. The sample configuration included with FWTK 2.1 does not enable HTTP tunneling.
Notified: April 19, 2002 Updated: February 10, 2003
Affected
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC tested InterScan VirusWall 3.52 on Windows 2000 and found it to be vulnerable. InterScan VirusWall can be used with a separate HTTP proxy service that may be able to block connections that use the HTTP CONNECT method. Web VirusWall for Windows NT requires a separate HTTP proxy service. This issue has been addressed in InterScan VirusWall for UNIX:
Updated: October 15, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: May 20, 2002
Unknown
No statement is currently available from the vendor regarding this vulnerability.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Updated: June 19, 2003
Affected
This problem has been fixed with the newest releases of WebWasher EE. General Availability (GA) release: WebWasher Proxy 3.4.1 Build 175 First Customer Shipment (FCS) release: WebWasher 4.0.0 Build 177 We fixed the problem end of July [2002] and that all version we released since contain this fix.
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.
Notified: April 19, 2002 Updated: May 29, 2002
Not Affected
[O] ur embedded web servers don't offer these capabilities [HTTP CONNECT method support].
The vendor has not provided us with any further information regarding this vulnerability.
The CERT/CC has no additional comments at this time.