Delmar is almost entirely correct. SET was designed to ride atop
application protocols, primarily HTTP and SMTP (by wrapping SET messages
in MIME). The design team wanted to ensure that the protocol would be
protected from firewall issues. This should ensure that no direct
interaction between SET and firewalls occurs, and that SET will work
through any firewall that can support HTTP and/or SMTP.
Mort
>
>----------
>From: dharris @
kcp .
com[SMTP:dharris @
kcp .
com]
>Sent: Friday, October 04, 1996 4:25 PM
>To: firewalls @
greatcircle .
com; Colin Campbell
>Subject: Re: Financial transactions and firewalls.
>
>Colin/list:
>
>The "gentleman" in question has many brothers and sisters in other fields. I
>have only been at this firewall stuff for about three years and I have
>already
>
>had to fight off three requests for "just a tiny hole" in my firewall so we
>could use the latest "firewalls unaware" application that we just _had_ to
>have.
>In each case the application developer was aghast when I suggested that the
>product would be much more useful if it was firewall aware _and_ based on a
>standard ("well understood") protocol like telnet, http, or ftp.
>
>Keep fighting the good fight. If it isn't firewalls aware it probably isn't
>security aware either.
>
>BTW: From a class I took at Interop I got the impression that SET is not
>incompatible with firewalls because it rides on top of other protocols which
>firewalls can handle. Is this impression correct?
>
> Delmer D. Harris
> dharris @
kcp .
com
>
>
>______________________________ Reply Separator
>_________________________________
>Subject: Financial transactions and firewalls.
>Author: Colin Campbell <sgcccdc%citec .
qld .
gov .
au @
cerberus2 .
kcp .
com> at
>INTERNET-MAIL
>Date: 10/3/96 4:14 PM
>
>
>Hi,
>
>I recently spent several hours (yes hours!) on the phone discussing the
>relative merits of my "stupid firewall philosophy" with a gentleman
>representing a company implementing secure financial services on the
>Internet. His service, if I understood correctly, was based on
>(something like?) SWIFT which has been in use in Europe for 15-20 years
>by many large financial institutions and therefore was not going to be
>changed quickly if at all.
>
>My firewall was stupid (based on fwtk) because it put proxies in bewteen
>my inside hosts and external servers. Furthermore, any firewall that did
>any sort of network address translation or proxying was brain-dead. (My
>interpretation of his statements).
>
>Why? Because his software passed an identifying "ticket" with every
>packet. This ticket comprised an encrypted date+time, the IP address of
>the client machine and some other stuff. When the server saw a packet
>from a host whose IP address did not match that in the ticket, alarm
>bells would sound and the fraud squad would be on the door step within
>minutes.
>
>When I suggested to him that 80% (just guessing, so be nice to me) of
>the firewalls outside of the financial world use NAT and or proxies he
>scoffed at the prospect, suggesting that people using such stupid
>technologies were going to miss out on the upcoming revolution about to
>hit the Internet with secure financial transactions that would not work
>through such firewalls. He also mentioned the "new Microsoft software"
>several times (anyone know which?).
>
>Does anyone have any comments on this guy's philosophy, or mine for that
>matter? I would especially like to hear from anyone who's been following
>the development of secure financial transactions (SET comes to mind,
>right track?) and how these systems are expected to operate through
>"stupid firewalls" like mine.
>
>Colin
>
>
>
|
|
