Re: Wrapping TCP communications in HTTP

SSL/TLS is an encryption and wire protocol, but has nothing to
do with sockets. FWIW, you perform the SSL encryption and
packet encapsilation _before_ you send the data through the
socket! How you communicate through the socket is entirely
up to you, overlapped I/O and IOCP are both fine...

--
=====================================
Alexander Nickolov
Microsoft MVP [VC], MCSD
email: agnickolov@xxxxxxxx
MVP VC FAQ: http://www.mvps.org/vcfaq
=====================================

"Mick" <Mick@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:A37AD254-3BEE-4FCC-9D31-8F6B95B1ECAB@xxxxxxxxxxxxxxxx
> That sounds like we might be able to get away with going through port 80
> by
> simply wrapping all of our messages in HTTP GETs or POSTs, although I
> suppose
> we would still have the problem of establishing the connection.
>
> I may be wrong, but I still don't think that going through HTTPS is going
> to
> work for us. There's the problem of connection validation (we don't have a
> web server), and it's still my understanding that HTTPS uses SSL which
> doesn't support overlapped I/O.
>
>
> "Alexander Nickolov" wrote:
>
>> That's because a firewall can enforce HTTP format for the traffic
>> through port 80. Use port 443 (HTTPS) instead.
>>
>> --
>> =====================================
>> Alexander Nickolov
>> Microsoft MVP [VC], MCSD
>> email: agnickolov@xxxxxxxx
>> MVP VC FAQ: http://www.mvps.org/vcfaq
>> =====================================
>>
>> "Mick" <Mick@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
>> news:0E1EEA8B-942C-40C2-9624-A10F04F1BA1A@xxxxxxxxxxxxxxxx
>> > Our data is binary, and our applications are not web browsers or web
>> > servers.
>> > We're using Winsock2 sockets with overlapped I/O through completion
>> > ports.
>> >
>> > The problem we have isn't security because we encrypt the data
>> > ourselves
>> > before it's put on the wire. What we need is a way to get through the
>> > firewall and be able to connect to our components (NT services). Most
>> > of
>> > our
>> > customers allow traffic through port 80, so when we want to create a
>> > socket
>> > connection from one machine to another machine this is behind the
>> > firewall
>> > we
>> > can specify the IP address of the machine and port 80. This works fine
>> > at
>> > most of our client's sites, but not all of them.
>> >
>> >
>> > "Alexander Nickolov" wrote:
>> >
>> >> Well, of course this helps nothing with security :). I just noticed
>> >> the intent of the original post. I've been handling this in the
>> >> completely wrong direction...
>> >>
>> >> To OP: HTTP won't help you a bit since it's not a secure protocol.
>> >> You need to use SSL/TLS to encrypt your data. If you are worried
>> >> about firewalls blocking ports, use the HTTPS port 443.
>> >>
>> >> --
>> >> =====================================
>> >> Alexander Nickolov
>> >> Microsoft MVP [VC], MCSD
>> >> email: agnickolov@xxxxxxxx
>> >> MVP VC FAQ: http://www.mvps.org/vcfaq
>> >> =====================================
>> >>
>> >> "Steve Alpert" <sra@xxxxxxxxxxxxxxxxx> wrote in message
>> >> news:OHT7gEc%23FHA.2176@xxxxxxxxxxxxxxxxxxxxxxx
>> >> > Mick wrote:
>> >> >> We have a set of applications that use TCP sockets (winsock2) to
>> >> >> communicate between machines. To communicate, a client machine
>> >> >> establishes a TCP socket connection to a server, then sends and
>> >> >> receives
>> >> >> messages using our own proprietary protocol. We have developed and
>> >> >> tested
>> >> >> all of this and it works fine. Now, because of firewall security
>> >> >> issues
>> >> >> at some of our customer sites, we would like to wrap these
>> >> >> communications
>> >> >> in the HTTP protocol. Is it possible to do this? If so, what would
>> >> >> be
>> >> >> required to implement this?
>> >> >>
>> >> >> I know very little about HTTP, but my understanding is that HTTP
>> >> >> communications requires that you establish a session with a server,
>> >> >> send
>> >> >> request messages to the server, and then wait to receive a
>> >> >> response.
>> >> >> Would this require us to scrap our existing socket implementation,
>> >> >> or
>> >> >> can
>> >> >> we just wrap our messages in HTTP?
>> >> >>
>> >> >> Any advice on how to implenent this will be much appreciated.
>> >> >> Thanks!
>> >> >>
>> >> >
>> >> > Although likely, most firewalls block ports and not protocols. That
>> >> > suggests they leave open port 80 (assuming http) and 443 (assuming
>> >> > https).
>> >> > They MAY check the envelopes but then again, maybe not!
>> >> >
>> >> > /steveA
>> >> >
>> >> > --
>> >> > Steve Alpert
>> >> > my email Fgrir_Nycreg @ vqk.pbz is encrypted with ROT13
>> >> > (www.rot13.org)
>> >> > and spaces
>> >> >
>> >>
>> >>
>> >>
>>
>>
>>


.

Relevant Pages
Quantcast