I'm writing a file transfer server, I'm going to use TLS to secure transmission. If I have a hostname for my server and use https then I can use hostname verification, but what if I don't have hostname and connect directly with ip address using socket?
I haven't said what frameworks you're planning to use of any further details about how it will work, but in a small talk way:
The RFC 2616 describes how a http protocol works, which is huge, but it says as part of this that the source ip should be set on the header section, some reversing dns can be made to get the hostname if it's not set as well
Under the hook a http is delivered by a non-persistent tcp socket connection which transfer a data frame between the client and server
TCP socket, now with some background when you open a tcp socket session from client to server you will get just the source/dest ip address and tcp port used, yes, this is the TCP/IP protocol in action, so from this point you will need to implement a kind of application protocol, because the socket is on transfer layer on TCP/IP model and https: technet.microsoft.com/en-gb/library/cc958821.aspx
PS: sorry about the broken link but stack overflow doesn't allow me to post more than 2 links, but I would recommend you to read about the SIO/OSI protocol model as well to understand more how the magic is done to get the internet working, but you got the ideia
So, I would recommend you to use the http with its beautiful TLS stuffs on a nginx server, it will be easier to manage in the future
but if you are just looking for some knowledge of how the stuffs work so go to create your own application layer like http with a header section, data section, file transfer control, send it by chunk and etc...
Related
I've installed Apache and I want to run an Apache webserver. I understand Apache is a HTTP Server but I wonder how can I force to use TCP or UDP when connecting to it. Should I configure ports on the server side? Should I use different ways to access the server on the client side?
The RFC specification of HTTP does say that HTTP can be run over other protocols than TCP, but this has never been done as far as I know. If you were going to try use another protocol for some reason you would need to choose one that has flow control like TCP does. UDP is not suitable.
Apache is designed to use TCP, and any change to this would require major changes to the source code.
I have an iOS app which is using ASIHTTPRequest to talk to a REST server. The server supports connections on port 80 (HTTP) and port 443 (HTTPS) - I'm using a GeoTrust/RapidSSL certificate on port 443. The user can configure the app to choose what protocol they want to use. I'm monitoring the traffic on the server using WireShark and what I'm finding is that occasionally if the user switches between HTTP and HTTPS, when they next submit a request then I can see traffic for both protocols, then every request after that is for the newly selected protocol only.
Also when the app is shutdown, there are a few packets sent which I guess is some kind of cleanup. The type of these final packets (HTTP/HTTPS) depends on what protocol the app has been using. If the app has been set to use both HTTP and HTTPS during the same app session, then both HTTP and HTTPS packets are sent when the app is shutdown. These scenarios don't seem right to me and suggest that my ASIHTTPRequest is not being completely cleared down. I am getting an occasional error when my request completes with the response 'HTTP/0.9 200 OK' but doesn't return any data and I think this is caused by trying to communicate with port 443 using HTTP.
Can anybody confirm my suspicions are true? Is there some command I should be using after an ASIHTTPRequest to clear it down so the next request can be sent on a different protocol?
What you are seeing is sounds like what HTTP persistent connections are meant to do; see http://en.wikipedia.org/wiki/HTTP_persistent_connection and so on.
There's nothing you need to do, none of this is doing any harm. The few http packets you see when switching protocols is just the old socket getting closed down I believe - I presume you are just seeing packets to TCP port 80, and aren't seeing any packets with data / actual http requests.
I am looking for a way to forward traffic from an application which goes to the web over port 443 to an instance of Fiddler running on my computer. Fiddler does not see this traffic while a packet trace application verified that the traffic is going out.
The application is foreign and I am not able to modify how it requests and it is not going through Internet Explorer (or apparently any other browser). If this app is going to an ip address (ie. 66.xxx.xx.xx port 443) or to a named host (ie. https://www.anysite.com), is there a way to tell my computer to forward this traffic to Fiddler, ie. to localhost port 8888?
I am not sure I am using the right terminology to describe this but and ideas would be appreciated!
Thanks,
David
If you can't get the application itself to send traffic to localhost on a specified port, then you need something lower level than Fiddler. Try WireShark.
http://www.wireshark.com/
#David: What's the application in question? Virtually all applications can be proxied, because those that can't aren't usable from most corporate networks. In some cases, you have to make minor changes to the environment (e.g. setting the proxy for the JVM). Some details are here: http://www.fiddler2.com/fiddler/help/hookup.asp
Using Netmon or Wireshark, you should be able to determine whether or not the application in question is making a request directly to a fixed IP address, or more likely, doing a DNS lookup first. If it's doing a DNS lookup first, you could edit your Windows Hosts file so that whateverthehostis.com points at 127.0.0.1. Because the hosts file only maps host to IP and not port to port, you'll need to adjust Fiddler to run on the target port that the application is looking for (use Tools > Fiddler Options for that).
Now, if the traffic is HTTPS (and I'm guessing it is) you're going to have a problem at that point, because Fiddler currently can only act as a HTTPS endpoint when it "knows" that the traffic is HTTPS by virtue of the client having opened a CONNECT tunnel first. This is something that could be adjusted in a future version of Fiddler, but it's not a common request.
I want to write a simple SMPP Server that basically forwards traffic to another SMPP server (C#, PHP). What are the things I need to know? How do I proceed?
With regards to Goran's comment, one possible solution would be a simple tcp proxy such as simpleproxy.
From the Ubuntu package description:
simpleproxy acts as a simple TCP proxy. It opens a listening socket on
the local machine and forwards any connection to a remote host. It can be
run as a daemon or through inetd.
Olaseni,
I've done something similar in the past, but i used perl. What i did was taking a port forwarding proxy which i downloaded from accordata.com. (port-proxy.pl)
I modified this to use the NET::SMPP module to validate PDU's when reading the incoming socket. Once the PDU was of type "Bind_request" i would validate against a dbase, replace credentials if validation was successfull and than forward or if credentials were not validated, issue a reject to the client and disconnect. Alternatively if the PDU contained anything else, i would forward using the logic that was already existing in port-proxy.pl.
You can write simple smpp lib and forward smpp traffic from many applications to the one smpp connection to the sms provider
I can advice you jsmpp lib, but it's for java. It's very simple and cool lib. Many low level things happen behind the scenes and you can focus on your business logic
Find more here
I have written exactly what you are asking for in vb.net
What i did was listen for inbound PDU (connect, bind, sms, and disconnect too) identifying each inbound connection uniquely - for the authentication bit,
then i forward the traffic onward to the delivery smsc.
Your SMPP service simply needs to listen for inbound PDU packets... as well as send heartbeat packets to the connected clients, if required.
So I've gone ahead and set up my ShoutCast server DNAS and set my DSP in Winamp on my host computer. The server listens on port 8000, so per some instructions I installed an output plugin for winamp (Shoutcast DSP) and used 8000 and the password to connect. Server accepts the connection.
Now, what the heck do I do now? My host computer is SSL secured and the DNAS server is installed within the secure web directory (if that matters). My desired end result is that I want to listen to my ShoutCast setup at home (host computer) from any computer.
I try browsing to my ip address and port 8000 (without using HTTPS) and it comes back with nothing. If I browse with HTTPS://my.server.com:8000, I get Error code: ssl_error_rx_record_too_long)
Have I completely missed something, or am I just a total moron?
Thanks.
SHOUTcast doesn't support SSL. The service on port 8000 is an unencrypted server for HTTP and ICY (the rather pointless SHOUTcast native streaming protocol, which is almost but not quite HTTP). The ssl_error_rx_record_too_long error is characteristic of trying to access a non-HTTPS service as HTTPS.
You should be able to connect to 8000 with your web browser and get the DNAS status page. If, on the other hand, you connect to that port with a media player, it'll return the direct MP3 stream. (Unfortunately, in an incredibly boneheaded piece of design, the way SHOUTcast decides which to respond with is by sniffing your User-Agent header for something beginning with Mozilla, so if you're using an alternative browser or blocking your UA you'll not be able to get the status, and if the stream's down you might just get nothing.)
To listen to a SHOUTcast server through SSL you would need to set up a proxy on another port that forwarded HTTPS requests to local HTTP requests; it'd also have to be a streaming-capable proxy, and you might need some hacks to stop ICY breaking it.
Probably easier, you could set up an SSH forwarded port from your client to the server. That would also be the only way to allow the DJ to connect to SHOUTcast with encryption, since the DJ protocol isn't HTTP compatible at all. Obviously SSH tunnels are no good for random public listeners though.
You could also try Icecast, an alternative to SHOUTcast that I believe has some SSL support (and also uses plain HTTP streaming instead of ICY).