How to tell if a port is an HTTP proxy
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
An Nmap result shows an HTTP proxy on port 8080. Without trying out the proxy, how can you tell if it's a proxy or not?
8080/tcp open http-proxy
proxy
edited Dec 25 '18 at 23:22
Peter Mortensen
2,14242124
asked Dec 25 '18 at 6:59
Bob EbertBob Ebert
1283
add a comment |
An Nmap result shows an HTTP proxy on port 8080. Without trying out the proxy, how can you tell if it's a proxy or not?
8080/tcp open http-proxy
proxy
edited Dec 25 '18 at 23:22
Peter Mortensen
2,14242124
asked Dec 25 '18 at 6:59
Bob EbertBob Ebert
1283
How certain do you need to be? If you merely want to avoid trying yourself, you could just trust metadata that commercial services likeshodanhave already acquired.
– anx
Dec 26 '18 at 7:30
add a comment |
An Nmap result shows an HTTP proxy on port 8080. Without trying out the proxy, how can you tell if it's a proxy or not?
8080/tcp open http-proxy
proxy
edited Dec 25 '18 at 23:22
Peter Mortensen
2,14242124
asked Dec 25 '18 at 6:59
Bob EbertBob Ebert
1283
An Nmap result shows an HTTP proxy on port 8080. Without trying out the proxy, how can you tell if it's a proxy or not?
8080/tcp open http-proxy
proxy
proxy
edited Dec 25 '18 at 23:22
Peter Mortensen
2,14242124
asked Dec 25 '18 at 6:59
Bob EbertBob Ebert
1283
edited Dec 25 '18 at 23:22
Peter Mortensen
2,14242124
asked Dec 25 '18 at 6:59
Bob EbertBob Ebert
1283
edited Dec 25 '18 at 23:22
Peter Mortensen
2,14242124
edited Dec 25 '18 at 23:22
Peter Mortensen
2,14242124
edited Dec 25 '18 at 23:22
Peter Mortensen
2,14242124
2,14242124
asked Dec 25 '18 at 6:59
Bob EbertBob Ebert
1283
asked Dec 25 '18 at 6:59
Bob EbertBob Ebert
1283
asked Dec 25 '18 at 6:59
Bob EbertBob Ebert
1283
1283
How certain do you need to be? If you merely want to avoid trying yourself, you could just trust metadata that commercial services likeshodanhave already acquired.
– anx
Dec 26 '18 at 7:30
add a comment |
How certain do you need to be? If you merely want to avoid trying yourself, you could just trust metadata that commercial services likeshodanhave already acquired.
– anx
Dec 26 '18 at 7:30
How certain do you need to be? If you merely want to avoid trying yourself, you could just trust metadata that commercial services like
shodan have already acquired.– anx
Dec 26 '18 at 7:30
How certain do you need to be? If you merely want to avoid trying yourself, you could just trust metadata that commercial services like
shodan have already acquired.– anx
Dec 26 '18 at 7:30
add a comment |
2 Answers
2
active
oldest
votes
It depends on the exact options you use for a port scan with nmap
at the most basic nmap will simply determine if a port is open and listening and do a name conversion of that port number to a service name based on
/etc/servicesor a similar table.
the actual service on a specific port such as8080may be something completely different and you will indeed need to do a lot more connecting and testing to get the actual servicewhen you use some of the more comprehensive options for service and version detection such as
-sV—version-allNmap will have already done a lot of finger printing and testing for you and then the service nmap reports will be pretty accurate
answered Dec 25 '18 at 10:06
HBruijnHBruijn
56.1k1190150
add a comment |
You can't tell.
Anybody can run any service on port 8080: regular HTTP proxy, HTTP CONNECT proxy, a regular HTTP server or even SSH server if you really want to!
HTTP is a protocol where the client sends a request before the server sends a greeting. Thus, if you connect to the port, you don't see anything. While this could be an indication of HTTP as the protocol, you can't tell if it's a server or a proxy, and also you can't be 100% certain the protocol is HTTP.
Many protocols have the server send a greeting before the client, like mail protocols, SSH, TLS (well, in SSH and TLS both client and server send a greeting). Thus, you can rule out some protocols by connecting to the port and observing whether there's a greeting. But you can't rule out them all, and even then, if you suspect the protocol is HTTP, you don't really know if it's a proxy or a server.
answered Dec 25 '18 at 16:53
juhistjuhist
17718
In SSH it used to be the case that clients would wait for the server to send its banner before the client would respond. However if you completely disable support for version 1 of the protocol it is possible for the client to send its banner without waiting for the server to say anything. For maximum compatibility SSH servers still need to send a banner before it has heard anything for the client. In the case of TLS it is different. The hello message from the server cannot be sent until after the client has sent a hello message.
– kasperd
Dec 25 '18 at 21:48
In TLS the client hello message contains a list of supported cipher suites. And the server picks one of the cipher suites supported by the client and in the server hello message tells the client which one it picked. For this reason it's not possible for the server to send a server hello message before it has received the client hello message. Moreover in some setups (usually involving a reverse proxy) the SNI field from the client hello is required before the server will be able to terminate the TLS connection.
– kasperd
Dec 25 '18 at 21:51
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "2"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f946556%2fhow-to-tell-if-a-port-is-an-http-proxy%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
It depends on the exact options you use for a port scan with nmap
at the most basic nmap will simply determine if a port is open and listening and do a name conversion of that port number to a service name based on
/etc/servicesor a similar table.
the actual service on a specific port such as8080may be something completely different and you will indeed need to do a lot more connecting and testing to get the actual servicewhen you use some of the more comprehensive options for service and version detection such as
-sV—version-allNmap will have already done a lot of finger printing and testing for you and then the service nmap reports will be pretty accurate
answered Dec 25 '18 at 10:06
HBruijnHBruijn
56.1k1190150
add a comment |
It depends on the exact options you use for a port scan with nmap
at the most basic nmap will simply determine if a port is open and listening and do a name conversion of that port number to a service name based on
/etc/servicesor a similar table.
the actual service on a specific port such as8080may be something completely different and you will indeed need to do a lot more connecting and testing to get the actual servicewhen you use some of the more comprehensive options for service and version detection such as
-sV—version-allNmap will have already done a lot of finger printing and testing for you and then the service nmap reports will be pretty accurate
answered Dec 25 '18 at 10:06
HBruijnHBruijn
56.1k1190150
add a comment |
It depends on the exact options you use for a port scan with nmap
at the most basic nmap will simply determine if a port is open and listening and do a name conversion of that port number to a service name based on
/etc/servicesor a similar table.
the actual service on a specific port such as8080may be something completely different and you will indeed need to do a lot more connecting and testing to get the actual servicewhen you use some of the more comprehensive options for service and version detection such as
-sV—version-allNmap will have already done a lot of finger printing and testing for you and then the service nmap reports will be pretty accurate
answered Dec 25 '18 at 10:06
HBruijnHBruijn
56.1k1190150
It depends on the exact options you use for a port scan with nmap
at the most basic nmap will simply determine if a port is open and listening and do a name conversion of that port number to a service name based on
/etc/servicesor a similar table.
the actual service on a specific port such as8080may be something completely different and you will indeed need to do a lot more connecting and testing to get the actual servicewhen you use some of the more comprehensive options for service and version detection such as
-sV—version-allNmap will have already done a lot of finger printing and testing for you and then the service nmap reports will be pretty accurate
answered Dec 25 '18 at 10:06
HBruijnHBruijn
56.1k1190150
answered Dec 25 '18 at 10:06
HBruijnHBruijn
56.1k1190150
answered Dec 25 '18 at 10:06
HBruijnHBruijn
56.1k1190150
answered Dec 25 '18 at 10:06
HBruijnHBruijn
56.1k1190150
56.1k1190150
add a comment |
add a comment |
You can't tell.
Anybody can run any service on port 8080: regular HTTP proxy, HTTP CONNECT proxy, a regular HTTP server or even SSH server if you really want to!
HTTP is a protocol where the client sends a request before the server sends a greeting. Thus, if you connect to the port, you don't see anything. While this could be an indication of HTTP as the protocol, you can't tell if it's a server or a proxy, and also you can't be 100% certain the protocol is HTTP.
Many protocols have the server send a greeting before the client, like mail protocols, SSH, TLS (well, in SSH and TLS both client and server send a greeting). Thus, you can rule out some protocols by connecting to the port and observing whether there's a greeting. But you can't rule out them all, and even then, if you suspect the protocol is HTTP, you don't really know if it's a proxy or a server.
answered Dec 25 '18 at 16:53
juhistjuhist
17718
In SSH it used to be the case that clients would wait for the server to send its banner before the client would respond. However if you completely disable support for version 1 of the protocol it is possible for the client to send its banner without waiting for the server to say anything. For maximum compatibility SSH servers still need to send a banner before it has heard anything for the client. In the case of TLS it is different. The hello message from the server cannot be sent until after the client has sent a hello message.
– kasperd
Dec 25 '18 at 21:48
In TLS the client hello message contains a list of supported cipher suites. And the server picks one of the cipher suites supported by the client and in the server hello message tells the client which one it picked. For this reason it's not possible for the server to send a server hello message before it has received the client hello message. Moreover in some setups (usually involving a reverse proxy) the SNI field from the client hello is required before the server will be able to terminate the TLS connection.
– kasperd
Dec 25 '18 at 21:51
add a comment |
You can't tell.
Anybody can run any service on port 8080: regular HTTP proxy, HTTP CONNECT proxy, a regular HTTP server or even SSH server if you really want to!
HTTP is a protocol where the client sends a request before the server sends a greeting. Thus, if you connect to the port, you don't see anything. While this could be an indication of HTTP as the protocol, you can't tell if it's a server or a proxy, and also you can't be 100% certain the protocol is HTTP.
Many protocols have the server send a greeting before the client, like mail protocols, SSH, TLS (well, in SSH and TLS both client and server send a greeting). Thus, you can rule out some protocols by connecting to the port and observing whether there's a greeting. But you can't rule out them all, and even then, if you suspect the protocol is HTTP, you don't really know if it's a proxy or a server.
answered Dec 25 '18 at 16:53
juhistjuhist
17718
In SSH it used to be the case that clients would wait for the server to send its banner before the client would respond. However if you completely disable support for version 1 of the protocol it is possible for the client to send its banner without waiting for the server to say anything. For maximum compatibility SSH servers still need to send a banner before it has heard anything for the client. In the case of TLS it is different. The hello message from the server cannot be sent until after the client has sent a hello message.
– kasperd
Dec 25 '18 at 21:48
In TLS the client hello message contains a list of supported cipher suites. And the server picks one of the cipher suites supported by the client and in the server hello message tells the client which one it picked. For this reason it's not possible for the server to send a server hello message before it has received the client hello message. Moreover in some setups (usually involving a reverse proxy) the SNI field from the client hello is required before the server will be able to terminate the TLS connection.
– kasperd
Dec 25 '18 at 21:51
add a comment |
You can't tell.
Anybody can run any service on port 8080: regular HTTP proxy, HTTP CONNECT proxy, a regular HTTP server or even SSH server if you really want to!
HTTP is a protocol where the client sends a request before the server sends a greeting. Thus, if you connect to the port, you don't see anything. While this could be an indication of HTTP as the protocol, you can't tell if it's a server or a proxy, and also you can't be 100% certain the protocol is HTTP.
Many protocols have the server send a greeting before the client, like mail protocols, SSH, TLS (well, in SSH and TLS both client and server send a greeting). Thus, you can rule out some protocols by connecting to the port and observing whether there's a greeting. But you can't rule out them all, and even then, if you suspect the protocol is HTTP, you don't really know if it's a proxy or a server.
answered Dec 25 '18 at 16:53
juhistjuhist
17718
You can't tell.
Anybody can run any service on port 8080: regular HTTP proxy, HTTP CONNECT proxy, a regular HTTP server or even SSH server if you really want to!
HTTP is a protocol where the client sends a request before the server sends a greeting. Thus, if you connect to the port, you don't see anything. While this could be an indication of HTTP as the protocol, you can't tell if it's a server or a proxy, and also you can't be 100% certain the protocol is HTTP.
Many protocols have the server send a greeting before the client, like mail protocols, SSH, TLS (well, in SSH and TLS both client and server send a greeting). Thus, you can rule out some protocols by connecting to the port and observing whether there's a greeting. But you can't rule out them all, and even then, if you suspect the protocol is HTTP, you don't really know if it's a proxy or a server.
answered Dec 25 '18 at 16:53
juhistjuhist
17718
answered Dec 25 '18 at 16:53
juhistjuhist
17718
answered Dec 25 '18 at 16:53
juhistjuhist
17718
answered Dec 25 '18 at 16:53
juhistjuhist
17718
17718
In SSH it used to be the case that clients would wait for the server to send its banner before the client would respond. However if you completely disable support for version 1 of the protocol it is possible for the client to send its banner without waiting for the server to say anything. For maximum compatibility SSH servers still need to send a banner before it has heard anything for the client. In the case of TLS it is different. The hello message from the server cannot be sent until after the client has sent a hello message.
– kasperd
Dec 25 '18 at 21:48
In TLS the client hello message contains a list of supported cipher suites. And the server picks one of the cipher suites supported by the client and in the server hello message tells the client which one it picked. For this reason it's not possible for the server to send a server hello message before it has received the client hello message. Moreover in some setups (usually involving a reverse proxy) the SNI field from the client hello is required before the server will be able to terminate the TLS connection.
– kasperd
Dec 25 '18 at 21:51
add a comment |
In SSH it used to be the case that clients would wait for the server to send its banner before the client would respond. However if you completely disable support for version 1 of the protocol it is possible for the client to send its banner without waiting for the server to say anything. For maximum compatibility SSH servers still need to send a banner before it has heard anything for the client. In the case of TLS it is different. The hello message from the server cannot be sent until after the client has sent a hello message.
– kasperd
Dec 25 '18 at 21:48
In TLS the client hello message contains a list of supported cipher suites. And the server picks one of the cipher suites supported by the client and in the server hello message tells the client which one it picked. For this reason it's not possible for the server to send a server hello message before it has received the client hello message. Moreover in some setups (usually involving a reverse proxy) the SNI field from the client hello is required before the server will be able to terminate the TLS connection.
– kasperd
Dec 25 '18 at 21:51
In SSH it used to be the case that clients would wait for the server to send its banner before the client would respond. However if you completely disable support for version 1 of the protocol it is possible for the client to send its banner without waiting for the server to say anything. For maximum compatibility SSH servers still need to send a banner before it has heard anything for the client. In the case of TLS it is different. The hello message from the server cannot be sent until after the client has sent a hello message.
– kasperd
Dec 25 '18 at 21:48
In SSH it used to be the case that clients would wait for the server to send its banner before the client would respond. However if you completely disable support for version 1 of the protocol it is possible for the client to send its banner without waiting for the server to say anything. For maximum compatibility SSH servers still need to send a banner before it has heard anything for the client. In the case of TLS it is different. The hello message from the server cannot be sent until after the client has sent a hello message.
– kasperd
Dec 25 '18 at 21:48
In TLS the client hello message contains a list of supported cipher suites. And the server picks one of the cipher suites supported by the client and in the server hello message tells the client which one it picked. For this reason it's not possible for the server to send a server hello message before it has received the client hello message. Moreover in some setups (usually involving a reverse proxy) the SNI field from the client hello is required before the server will be able to terminate the TLS connection.
– kasperd
Dec 25 '18 at 21:51
In TLS the client hello message contains a list of supported cipher suites. And the server picks one of the cipher suites supported by the client and in the server hello message tells the client which one it picked. For this reason it's not possible for the server to send a server hello message before it has received the client hello message. Moreover in some setups (usually involving a reverse proxy) the SNI field from the client hello is required before the server will be able to terminate the TLS connection.
– kasperd
Dec 25 '18 at 21:51
add a comment |
Thanks for contributing an answer to Server Fault!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fserverfault.com%2fquestions%2f946556%2fhow-to-tell-if-a-port-is-an-http-proxy%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
How certain do you need to be? If you merely want to avoid trying yourself, you could just trust metadata that commercial services like
shodanhave already acquired.– anx
Dec 26 '18 at 7:30