I just released mod_lisp 2.0 here :
http://www.fractalconcept.com/asp/mod_lisp
mod_lisp is an Apache module to easily write web applications in Lisp.
It has been completely re-written and now it reuses the Apache <-> Lisp
sockets, boosting performance by a factor of up to 80.
mod_lisp talk from Apache to lisp processes by sockets with a very
straightforward protocol to handle a request. It now reuses the Apache to
Lisp sockets for improved performance. Future versions will probably be more
Lisp specific, but for now it can be used by any other language.
Why mod_lisp?
-The Lisp servers are application servers. I don't want to bother the Lisp
applications with things like serving gif or jpeg files or even static pages
in some cases. Using mod_lisp I can separate the HTTP servers from the
application servers.
The architecture I am promoting is like this: One or more Apache front ends
to serve static content (like images), one or more Lisp application servers
to process the application logic and databases servers to store the data.
-Time is the scarcest resource so I don't want to waste it to implement
things like SSL (though an SSL implementation in Lisp is useful for other
purposes), keeping up to date with HTTP protocols etc. The Apache people do
this with a sufficient quality, I don't see any interest to do it myself.
-I can benefit from the Apache modules if I need them (mod_gzip for
instance)
-The market acceptance is quite better. It's really easier to sell an Apache
+ FreeBSD + (Postgresql or Oracle) + Lisp solution than a Lisp + FreeBSD +
(Postgresql or Oracle) solution. In the first case Lisp is perceived as yet
another web language like Perl, Python and others. In the second case you
have to advocate the use of Lisp.
-mod_lisp is released under a FreeBSD style license.
-It's easier to work on a project where the Lisp web application is only a
part of a web site.
It's in a beta stage. So please report the bugs you can find to me so that I
can include them. (you can also report to me the English mistakes I have
made in the mod_lisp pages...)
Marc
Hey Marc,
What did you compile your dll for windows with? When I try to apache to
load it I get an error about some missing support for the mod_lisp dll.
I also noticed that since it is possible for apache to load a dll that it
would be possible to write a LispWorks dll to directly interface to apache
and bypass the sockets altogether. Direct calls into Lisp. Just an idea.
Wade
"Wade Humeniuk" <········@cadvision.com> wrote
> What did you compile your dll for windows with? When I try to apache to
> load it I get an error about some missing support for the mod_lisp dll.
Visual C++ 6.0. What error do you get ?
> I also noticed that since it is possible for apache to load a dll that it
> would be possible to write a LispWorks dll to directly interface to apache
> and bypass the sockets altogether. Direct calls into Lisp. Just an idea.
It could be possible but this will only work with LispWorks, ACL and may be
Corman Lisp. Also, the multi-processing can be tricky.
And I much prefer to have my full LispWorks environment and to be able to
work on a live system.
This morning, I modified several times the application while it was running
with people connected. For instance I noticed that some people tried the
directory only part of the mod_lisp URI (with the session Id). As I had no
page name I had an error like "nil is not a view" replied to the user. So I
added some code to deal with this while the server was running. Isn't Lisp
brilliant?
Marc
"Marc Battyani" <·············@fractalconcept.com> wrote in message
·······················································@lp.airnews.net...
>
> "Wade Humeniuk" <········@cadvision.com> wrote
>
> > What did you compile your dll for windows with? When I try to apache to
> > load it I get an error about some missing support for the mod_lisp dll.
>
> Visual C++ 6.0. What error do you get ?
C:\Program Files\Apache Group\Apache\conf>..\apache.exe -w -f
c:\progra~1\apache~1\apache\conf\httpd.conf
..\apache.exe -w -f c:\progra~1\apache~1\apache\conf\httpd.conf
Syntax error on line 204 of c:/program files/apache
group/apache/conf/httpd.conf:
Cannot load c:/program files/apache
group/apache/modules/apachemodulelisp.dll into server: (1157) One of the
library files needed to run this application cannot be found:
C:\Program Files\Apache Group\Apache\conf>
Wade
"Wade Humeniuk" <········@cadvision.com> wrote
> C:\Program Files\Apache Group\Apache\conf>..\apache.exe -w -f
> c:\progra~1\apache~1\apache\conf\httpd.conf
> ..\apache.exe -w -f c:\progra~1\apache~1\apache\conf\httpd.conf
> Syntax error on line 204 of c:/program files/apache
> group/apache/conf/httpd.conf:
> Cannot load c:/program files/apache
> group/apache/modules/apachemodulelisp.dll into server: (1157) One of the
> library files needed to run this application cannot be found:
Here is what I have in my httpd.conf on my Win32 box:
...
LoadModule lisp_module modules/ApacheModuleLisp.dll
...
LispServer 127.0.0.1 3000 "Fractal"
...
<Location /asp>
SetHandler lisp-handler
</Location>
I've put "ApacheModuleLisp.dll" in the "modules" directory of Apache.
If this does not work try to copy another Apache module DLL as
ApacheModuleLisp.dll to see if you get the same errors.
You can email me directly if you want.
Marc
hey,
marc> -Time is the scarcest resource so I don't want to waste it to
marc> implement things like SSL (though an SSL implementation in Lisp
marc> is useful for other purposes), keeping up to date with HTTP
marc> protocols etc. The Apache people do this with a sufficient
marc> quality, I don't see any interest to do it myself.
I wonder if something from another post might be useful here as well.
The idea of port forwarding is what I mean. Suppose you had this SSL
service running on the server. The way it worked is that you ask it
for an SSL socket (i.e. the accept-connection using SSL), and it
somehow forward the SSL stuff to a non-SSL TCP/IP socket server on the
same box, listening only to localhost.
So what you'd do in CL is to write your typical TCP/IP server, where
you simply make sure only to accept connections from localhost. Then
you set up an SSL socket server which, for each request, immediatly
opens another TCP/IP connection to the Lisp server on localhost. That
way, data stays encrypted over the network, and you don't have to do
SSL in Lisp. Just a very simple echo-style level of indirection. It
would probably be so fast that it would go unnoticed.
just a thought,
dave
David Bakhash <·····@alum.mit.edu> writes:
> So what you'd do in CL is to write your typical TCP/IP server, where
> you simply make sure only to accept connections from localhost. Then
> you set up an SSL socket server which, for each request, immediatly
> opens another TCP/IP connection to the Lisp server on localhost. That
> way, data stays encrypted over the network, and you don't have to do
> SSL in Lisp. Just a very simple echo-style level of indirection. It
> would probably be so fast that it would go unnoticed.
Is it, in general, guaranteed across all modern operating systems that
socket to socket localhost does a loopback that isn't sniffable by external
network hardware?
- - -
Unrelated to this, what does mod_lisp normally use for its outboard lisp
(i.e., what vendors is it ported to, or is it a lisp of its own)
and for its ipc substrate?
"Kent M Pitman" <······@world.std.com> wrote
> Unrelated to this, what does mod_lisp normally use for its outboard lisp
> (i.e., what vendors is it ported to, or is it a lisp of its own)
> and for its ipc substrate?
mod_lisp is just a connector between an Apache server and Lisp processes (on
the same or other computers).
You can use mod_lisp with any Lisp you want. In my setup I have an Apache
server on a FreeBSD box and 2 application servers running LW (a Win2000 box
and a FreeBSD box).
I released mod_lisp with a FreeBSD style License so that people can use it
for commercial work.
More info here : www.fractalconcept.com/asp/mod_lisp
Marc
Kent M Pitman <······@world.std.com> wrote:
+---------------
| David Bakhash <·····@alum.mit.edu> writes:
| > you set up an SSL socket server which, for each request, immediatly
| > opens another TCP/IP connection to the Lisp server on localhost.
|
| Is it, in general, guaranteed across all modern operating systems that
| socket to socket localhost does a loopback that isn't sniffable by external
| network hardware?
+---------------
For most values of "modern operating system", yes. In BSD-derived stacks,
"localhost" is a purely software construct. The packets never touch the
hardware (other than memory & CPU, that is).
However... It's possible that a rogue program [virus, Trojan, whatever]
*on* the SSL server could connect via localhost to the Lisp server
and spoof the SSL server, causing the Lisp server to respond to a
request that didn't come through the SSL server. [Of course, if an
attacker can get a virus or Trojan onto the SSL server host, you're
already in serious trouble...]
-Rob
-----
Rob Warnock, 31-2-510 <····@sgi.com>
SGI Network Engineering <http://reality.sgi.com/rpw3/> [until 8/15]
1600 Amphitheatre Pkwy. Phone: 650-933-1673
Mountain View, CA 94043 PP-ASEL-IA
[Note: ·········@sgi.com and ········@sgi.com aren't for humans ]
"David Bakhash" <·····@alum.mit.edu> wrote in message
···················@alum.mit.edu...
> hey,
>
> marc> -Time is the scarcest resource so I don't want to waste it to
> marc> implement things like SSL (though an SSL implementation in Lisp
> marc> is useful for other purposes), keeping up to date with HTTP
> marc> protocols etc. The Apache people do this with a sufficient
> marc> quality, I don't see any interest to do it myself.
>
> I wonder if something from another post might be useful here as well.
> The idea of port forwarding is what I mean. Suppose you had this SSL
> service running on the server. The way it worked is that you ask it
> for an SSL socket (i.e. the accept-connection using SSL), and it
> somehow forward the SSL stuff to a non-SSL TCP/IP socket server on the
> same box, listening only to localhost.
>
> So what you'd do in CL is to write your typical TCP/IP server, where
> you simply make sure only to accept connections from localhost. Then
> you set up an SSL socket server which, for each request, immediatly
> opens another TCP/IP connection to the Lisp server on localhost. That
> way, data stays encrypted over the network, and you don't have to do
> SSL in Lisp. Just a very simple echo-style level of indirection. It
> would probably be so fast that it would go unnoticed.
Here is what I posted on the SSL subject 2 weeks ago.
>From: Marc Battyani (·············@fractalconcept.com)
>Subject: Re: New Release of AServe for LW
>Newsgroups: comp.lang.lisp
>Date: 2001-06-06 05:30:28 PST
...
>With LispWorks under FreeBSD and W2K I use this:
>For HTTPS I use Apache+mod_ssl with mod_lisp
>For direct (non HTTP) SSL connection I will look at Stunnel :
>http://www.stunnel.org/ Seems an easy solution while waiting for a well
>integrated LW SSL.
BTW I haven't found the time to look at Stunnel...
Marc
David Bakhash wrote:
> hey,
>
> I wonder if something from another post might be useful here as well.
> The idea of port forwarding is what I mean. Suppose you had this SSL
> service running on the server. The way it worked is that you ask it
> for an SSL socket (i.e. the accept-connection using SSL), and it
> somehow forward the SSL stuff to a non-SSL TCP/IP socket server on the
> same box, listening only to localhost.
>
> So what you'd do in CL is to write your typical TCP/IP server, where
> you simply make sure only to accept connections from localhost. Then
> you set up an SSL socket server which, for each request, immediatly
> opens another TCP/IP connection to the Lisp server on localhost. That
> way, data stays encrypted over the network, and you don't have to do
> SSL in Lisp. Just a very simple echo-style level of indirection. It
> would probably be so fast that it would go unnoticed.
I don't really understand why this is understood as a so big problem...
Is including SSL with Lisp *so* difficult that it _really_ needs such a
fragile and in cryptographic sight "questionable" thing?
Creating a SSL encoded connection with OpenSSL doesn't mean that you have
to reinvent the wheel in lisp-systems - if the Lispsystem is able to give
you the socket-descriptor of a socket-stream opened the ususal way
then you simply have to call several C-Functions to initialize the SSL
connections and then do all I/O using SSL_write and SSL_read. The only real
work would be to integrate SSL_write and SSL_read in a nice manner into the
CL streams.
Enabling generic SSL support for Lisp using the FFI is not so tricky like
doing a binding to a GUI-toolkit as no callbacks into Lisp are needed to
get it working.
There actually _are_ callbacks in SSL - they are used to allow hooking in a
function to read a password that is then used to decrypt the private-key.
ACL doesn't use this callbacks and therefore is not able to handle
encrypted PEMs.
If you _really_ would prefer a forwarding setting than you can use tools
like stunnel or so to do this. IMHO this tools are fragile hacks that
should be used if it doesn't pay to enhance a software anymore - IMHO
Common Lisp is worth the effort of integrating _real_ SSL support.
ciao,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
> I don't really understand why this is understood as a so big problem...
> Is including SSL with Lisp *so* difficult that it _really_ needs such a
> fragile and in cryptographic sight "questionable" thing?
EVEN IF it were a totally trivial technical issue, and I bet it's not,
the problems of US export laws make this whole area of code creation a
nightmare for us that you might not see from across the ocean. If a
solution exists that puts the burden of downloading the cryptographically
correct components on someone else rather than on Lisp, I'd say that was
a win in and of itself.
But also, isn't SSL written to assume 32 bit arithmetic, and isn't
that problematic from a type-bits + gc standpoint since 32 bit numbers
are usually tricky to slice and dice without making garbage in Lisp?
I've found other weird checksumming code (md5, perhaps?, can't recall)
to be a pain in the neck this way. I've never seen an SSL spec, so
don't know if it has the same issue.
Also, reducing the number of places that Lisp gets involved simplifies
the overhead of getting it on-site at places.
And, finally, I've been meaning to ask this about AllegroServe. Maybe this
is as good a time as any:
In the LW port of AllegroServe which you did, you end up with all the
subprocesses running within Lisp, rather than as forked processes. Does
this happen in Franz? Because this means the Lisp itself has to run either
all as root or all as nobody (or httpd or whetever). Each has its problems.
By contrast, Apache seems to have a single process that is root which is
accepting connections on privileged port 80 and then it hands off the work
to other processes that are not privileged. It's easier to understand/manage
the security issues in the Apache model, and I'm at a loss to figure out
exactly how to get LW to do this (not necessarily because LW can't do it;
maybe partly because I either haven't the system programming experience to
know what question to ask or because I haven't read the right documentation).
Nevertheless, it's plain there are a lot of tricky complications here, and
they are all solved if one uses Apache in the style that it sounds like
mod_lisp is doing.
Not to mention the fact that the mod_lisp approach allows you access to other,
non-lisp server modules without requiring you to implement an interface
to those...
Kent M Pitman wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>
>> I don't really understand why this is understood as a so big problem...
>> Is including SSL with Lisp *so* difficult that it _really_ needs such a
>> fragile and in cryptographic sight "questionable" thing?
>
> EVEN IF it were a totally trivial technical issue, and I bet it's not,
> the problems of US export laws make this whole area of code creation a
> nightmare for us that you might not see from across the ocean. If a
> solution exists that puts the burden of downloading the cryptographically
> correct components on someone else rather than on Lisp, I'd say that was
> a win in and of itself.
I see the problems but it is not much different to what I plan for doing
SSL in Lisp. After doing some investigations I come to the conclusion
(which was my first intuitive conclusion too), that it would be somewhat of
a waste of time to reinvent all the functionality of OpenSSL in "pure" Lisp.
If you use actual possible approaches (mod_ssl in Apache, stunnel) you would
need OpenSSL too - so if you can manage to download Apache, mod_ssl and
OpenSSL then you should be able too to download OpenSSL and CL-SSL (name
arbitrary chosen)
> But also, isn't SSL written to assume 32 bit arithmetic, and isn't
> that problematic from a type-bits + gc standpoint since 32 bit numbers
> are usually tricky to slice and dice without making garbage in Lisp?
> I've found other weird checksumming code (md5, perhaps?, can't recall)
> to be a pain in the neck this way. I've never seen an SSL spec, so
> don't know if it has the same issue.
SSL is only a cryptographic network protocol. It uses several well-known
Crypto-algorithms for different tasks.
Key-Exchangement: e.g. RSA, Diffie Hellman
Here would be no real problems for doing this in pure Lisp - Lisp already
supports Bignums and my implementation of RSA shows that it is possible
to implement RSA with minimal effort in Lisp. To make it _really_ fast in
Lisp would need some non-trivial low-level add-ons like "Montgomery
Exponentiation" (less MOD operations...)
Authentication/checksumming (e.g of packets): MD5, SHA-1, SHA-256
Here you're right - the only Lisp I now of that could make it possible to
implement this stuff fast is probably CMUCL. There nothing special that MD5
*and* SHA have this problem as SHA is simply an enhanced version of MD5.
Encryption/Decryption (DES, Triple-DES, RC4, RC5)
DES and Triple-DES use some 32 bit arithmetic. I do not remember If it
could be implemented efficiently using 16 bit arithmetic but I think so
(because DES is so old that 32 bit machines were not the usual case)
I no nothing interesting of RC5 - AFAIK it's proprietary.
RC4 (or ARC4) was a proprietary Stream-Cipher algorithm. Somedays some
anonymous Guy posted an algorithm to a newsgroup that seemed to implement
the proprietary RC4. Nowadays you should be able to use RC4 without any
troubles. As RC4 is a byte-oriented stream-cipher there are *no* problems
implementing it in Common Lisp. You'll need fast access to byte-arrays.
> Also, reducing the number of places that Lisp gets involved simplifies
> the overhead of getting it on-site at places.
This is another reason why I vote for OpenSSL - why two (or three if you
have Java) SSL packages on a machine if one package is enough?
(I hope I've understood you right here)
> And, finally, I've been meaning to ask this about AllegroServe. Maybe
> this is as good a time as any:
>
> In the LW port of AllegroServe which you did, you end up with all the
> subprocesses running within Lisp, rather than as forked processes. Does
> this happen in Franz?
The lightweight multithreading is exactly the same as in the ACL version.
> Because this means the Lisp itself has to run
> either
> all as root or all as nobody (or httpd or whetever). Each has its
> problems. By contrast, Apache seems to have a single process that is root
> which is accepting connections on privileged port 80 and then it hands off
> the work
> to other processes that are not privileged. It's easier to
> understand/manage the security issues in the Apache model, and I'm at a
> loss to figure out exactly how to get LW to do this (not necessarily
> because LW can't do it; maybe partly because I either haven't the system
> programming experience to know what question to ask or because I haven't
> read the right documentation). Nevertheless, it's plain there are a lot of
> tricky complications here, and they are all solved if one uses Apache in
> the style that it sounds like mod_lisp is doing.
AServe supports forking of childprocesses including changing the UID. I've
to say that this is _not_ tested in the LispWorks port - it _may_ work
(I've implemented the foreign-calls) but it may smoke your monitor and
harddisk in the pipe... ;-)
> Not to mention the fact that the mod_lisp approach allows you access to
> other, non-lisp server modules without requiring you to implement an
> interface to those...
Hm... I can reverse this in "AServe let's you include lisp-server modules
that are not available in Apache". I don't want to start a flamewar on this
- IMHO there are reasons for using mod_lisp and there are reasons for using
a complete CommonLisp Webserver like AServe. If I develop a Lispapplication
that should then offer some Webinterface or needs HTTP-Client access *I*
would prefer to use AServe. Think of e.g a implementation of XML-RPC or
SOAP for Lisp - would you _really_ want to depend on a another (big)
non-Lisp application like Apache?
I don't think that it is possible to integrate Apache as good into Lisp as
this is possible with Lisp webservers like CL-HTTPD and AServe. So if the
main part of a application relies on Lisp - I see no real alternative than
using CL-HTTPD or AServe. If the main part lies in the Web-server parts a
Apache based solution might be better. I'm not sure but AFAIK it is
possible to use AServe as a Proxy that relies on a Apache server for the
main work. AServe is rather lightweight - so using it combined with Apache
would certainly be an alternative.
ciao,
Jochen
jochen> If the main part lies in the Web-server parts a Apache based
jochen> solution might be better. I'm not sure but AFAIK it is
jochen> possible to use AServe as a Proxy that relies on a Apache
jochen> server for the main work. AServe is rather lightweight - so
jochen> using it combined with Apache would certainly be an
jochen> alternative.
This is correct, and I agree that this is the best way to handle
serving web pages with Lisp. Apache does its thing well, and it would
be hard to imagine a Lisp-based web server that could compete with
Apache in the near future. Best to use the web proxy feature of
Apache.
In another way, one can argue that the mod_* is a major Apache feature
-- perhaps more widely used. But I believe that a single Lisp process
managing the different Lisp-based requests is nicer, and AServe is
pretty small and simple, and so you end up getting more functionality
while still being able to leverage what Apache offers.
dave
"David Bakhash" <·····@alum.mit.edu> wrote
> jochen> If the main part lies in the Web-server parts a Apache based
> jochen> solution might be better. I'm not sure but AFAIK it is
> jochen> possible to use AServe as a Proxy that relies on a Apache
> jochen> server for the main work. AServe is rather lightweight - so
> jochen> using it combined with Apache would certainly be an
> jochen> alternative.
> This is correct, and I agree that this is the best way to handle
> serving web pages with Lisp. Apache does its thing well, and it would
> be hard to imagine a Lisp-based web server that could compete with
> Apache in the near future. Best to use the web proxy feature of
> Apache.
Again, mod_lisp is exactly designed to do this. (Glue an external Lisp
process to an Apache server)
See my other post in reply to Jochen.
Marc
"Jochen Schmidt" <···@dataheaven.de> wrote
> Hm... I can reverse this in "AServe let's you include lisp-server modules
> that are not available in Apache". I don't want to start a flamewar on
this
> - IMHO there are reasons for using mod_lisp and there are reasons for
using
> a complete CommonLisp Webserver like AServe. If I develop a
Lispapplication
> that should then offer some Webinterface or needs HTTP-Client access *I*
> would prefer to use AServe. Think of e.g a implementation of XML-RPC or
> SOAP for Lisp - would you _really_ want to depend on a another (big)
> non-Lisp application like Apache?
> I don't think that it is possible to integrate Apache as good into Lisp as
> this is possible with Lisp webservers like CL-HTTPD and AServe. So if the
> main part of a application relies on Lisp - I see no real alternative than
> using CL-HTTPD or AServe. If the main part lies in the Web-server parts a
> Apache based solution might be better. I'm not sure but AFAIK it is
> possible to use AServe as a Proxy that relies on a Apache server for the
> main work. AServe is rather lightweight - so using it combined with Apache
> would certainly be an alternative.
I think you misunderstood what mod_lisp is.
mod_lisp is essentially a thin, fast and optimized for Lisp proxy module.
You can (and you should if you are using AServe behind Apache) use mod_lisp
with AServe. The modifications to do to AServe are not very difficult.
mod_lisp is not an application framework for web applications like IMHO for
instance. You can use, and in fact you need, a Lisp application to process
the requests. In fact IMHO uses a similar module intended for Java.
mod_lisp gets the requests inside Apache, forwards them to the Lisp
processes, gets the reply from the Lisp processes and finally gives the
reply to Apache that sends is to the user.
Marc
Marc Battyani wrote:
>
> "Jochen Schmidt" <···@dataheaven.de> wrote
>
>> Hm... I can reverse this in "AServe let's you include lisp-server modules
>> that are not available in Apache". I don't want to start a flamewar on
> this
>> - IMHO there are reasons for using mod_lisp and there are reasons for
> using
>> a complete CommonLisp Webserver like AServe. If I develop a
> Lispapplication
>> that should then offer some Webinterface or needs HTTP-Client access *I*
>> would prefer to use AServe. Think of e.g a implementation of XML-RPC or
>> SOAP for Lisp - would you _really_ want to depend on a another (big)
>> non-Lisp application like Apache?
>> I don't think that it is possible to integrate Apache as good into Lisp
>> as this is possible with Lisp webservers like CL-HTTPD and AServe. So if
>> the main part of a application relies on Lisp - I see no real alternative
>> than using CL-HTTPD or AServe. If the main part lies in the Web-server
>> parts a Apache based solution might be better. I'm not sure but AFAIK it
>> is possible to use AServe as a Proxy that relies on a Apache server for
>> the main work. AServe is rather lightweight - so using it combined with
>> Apache would certainly be an alternative.
>
> I think you misunderstood what mod_lisp is.
> mod_lisp is essentially a thin, fast and optimized for Lisp proxy module.
> You can (and you should if you are using AServe behind Apache) use
> mod_lisp with AServe. The modifications to do to AServe are not very
> difficult. mod_lisp is not an application framework for web applications
> like IMHO for instance. You can use, and in fact you need, a Lisp
> application to process the requests. In fact IMHO uses a similar module
> intended for Java. mod_lisp gets the requests inside Apache, forwards them
> to the Lisp processes, gets the reply from the Lisp processes and finally
> gives the reply to Apache that sends is to the user.
Yes - I know what mod_lisp is and does - and I've never said that there is
anything inherently wrong with this approach. The difference to the
alternative I outlined is that AServe is by itself a standalone Webserver.
You could contact it directly *or* through mod_proxy. The "package" AServe
contains *alot* of useful things like the HTMLGEN macros a webclient and
much more.
It is rather easy to code webapplications using AServe. IMHO AServe has
exactly the right feature-set so that it can be used out-of-the-box but is
not bloated.
If you have mod_lisp then you _need_ some real Webserver (Apache) and on
the Lisp side more work than with AServe to process typical requests
(correct me if I'm wrong).
AServe does not try to be another Apache - AServe tries to be ...AServe
("douh" ;-) )
IMHO there are two different kinds of Webservers
a) Apache, IIS ...
This are real workinghorses that could and should withstand alot of traffic.
they get optimized for performance and should support things like
clustering a.s.o. they are IMHO intended to run in typical medium to large
corporate settings. Yes you "could" use them on your workstation but IMHO
it's a waste of ressources if you don't need them the whole time.
b) Application-scale Webservers
Many applications today need access to the Web. E.g you can give your
application a portable network-transparent GUI. The effort taken to get
this application-GUI served over a Apache-Server is ridiculous. It is much
easier to export an Application-GUI to a Webserver if the Server is _part_
of the application. With an embedded Webserver like CL-HTTPD or AServe your
application is still a complete independent package. Another example is e.
g. XML-RPC. If you want to implement XML-RPC _server_ support for Lisp you
need a Webserver that takes the requests and makes it available to your
application. This is too much more standalone and independent if you don't
need a installed Apache somewhere but can simply use AServe as a
lightweight http-library for Lisp.
With mod_proxy it is possible to combine the best from this two worlds. You
can easily deploy your Applications as they are completely standalone, but
you can integrate them equally easily into a fixed corporate-setting that
uses Apache as their main-server.
If you use mod_lisp you loose the capability to easily deploy the
application and if you do the Apache/CGI way you loose not only performance
but also usable stateful sessions that are needed for real applications.
ciao,
Jochen
"Jochen Schmidt" <···@dataheaven.de> wrote
> Marc Battyani wrote:
>
> Yes - I know what mod_lisp is and does - and I've never said that there is
> anything inherently wrong with this approach. The difference to the
> alternative I outlined is that AServe is by itself a standalone Webserver.
> You could contact it directly *or* through mod_proxy. The "package" AServe
> contains *alot* of useful things like the HTMLGEN macros a webclient and
> much more.
> It is rather easy to code webapplications using AServe. IMHO AServe has
> exactly the right feature-set so that it can be used out-of-the-box but is
> not bloated.
>
> If you have mod_lisp then you _need_ some real Webserver (Apache) and on
> the Lisp side more work than with AServe to process typical requests
> (correct me if I'm wrong).
Yes you are wrong (Seems we have some kind of communication pb. ;-))
mod_lisp does nothing to process the request. It just forward it to the Lisp
process. On the Lisp process you must have some kind of application like
AServe, IMHO or whatever.
mod_lisp is essentially a thin, fast and optimized for Lisp mod_proxy.
> AServe does not try to be another Apache - AServe tries to be ...AServe
> ("douh" ;-) )
> IMHO there are two different kinds of Webservers
> a) Apache, IIS ...
> This are real workinghorses that could and should withstand alot of
traffic.
> they get optimized for performance and should support things like
> clustering a.s.o. they are IMHO intended to run in typical medium to large
> corporate settings. Yes you "could" use them on your workstation but IMHO
> it's a waste of ressources if you don't need them the whole time.
>
> b) Application-scale Webservers
> Many applications today need access to the Web. E.g you can give your
> application a portable network-transparent GUI. The effort taken to get
> this application-GUI served over a Apache-Server is ridiculous. It is much
> easier to export an Application-GUI to a Webserver if the Server is _part_
> of the application. With an embedded Webserver like CL-HTTPD or AServe
your
> application is still a complete independent package. Another example is e.
> g. XML-RPC. If you want to implement XML-RPC _server_ support for Lisp you
> need a Webserver that takes the requests and makes it available to your
> application. This is too much more standalone and independent if you don't
> need a installed Apache somewhere but can simply use AServe as a
> lightweight http-library for Lisp.
> With mod_proxy it is possible to combine the best from this two worlds.
With mod_lisp also as it has been done _exactly_ to do this, sigh...
>You
> can easily deploy your Applications as they are completely standalone, but
> you can integrate them equally easily into a fixed corporate-setting that
> uses Apache as their main-server.
> If you use mod_lisp you loose the capability to easily deploy the
> application and if you do the Apache/CGI way you loose not only
performance
> but also usable stateful sessions that are needed for real applications.
No. Again, mod_lisp is intended to replace mod_proxy, not to replace AServe.
Every Lisp application that hide behind Apache through mod_proxy should use
mod_lisp instead.
Marc
Marc Battyani wrote:
> Yes you are wrong (Seems we have some kind of communication pb. ;-))
>
> mod_lisp does nothing to process the request. It just forward it to the
> Lisp process. On the Lisp process you must have some kind of application
> like AServe, IMHO or whatever.
> mod_lisp is essentially a thin, fast and optimized for Lisp mod_proxy.
The difference is that mod_proxy doesn't depend on a Lisp at it's end while
mod_lisp does (by definition and intend).
>> of the application. With an embedded Webserver like CL-HTTPD or AServe
> your
>> application is still a complete independent package. Another example is
>> e. g. XML-RPC. If you want to implement XML-RPC _server_ support for Lisp
>> you need a Webserver that takes the requests and makes it available to
>> your application. This is too much more standalone and independent if you
>> don't need a installed Apache somewhere but can simply use AServe as a
>> lightweight http-library for Lisp.
>
>> With mod_proxy it is possible to combine the best from this two worlds.
> With mod_lisp also as it has been done _exactly_ to do this, sigh...
No - you cannot create a standalone XML-RPC serving Lispapplication.
(Standalone in the sense of "no external Webserver needed")
mod_lisp is intended to be the glue between a Lisp and a Webserver (Apache).
What I described was the situation where the Webserver already sits *in*
the Lisp so there's no glue needed.
>>You
>> can easily deploy your Applications as they are completely standalone,
>> but you can integrate them equally easily into a fixed corporate-setting
>> that uses Apache as their main-server.
>
>> If you use mod_lisp you loose the capability to easily deploy the
>> application and if you do the Apache/CGI way you loose not only
> performance
>> but also usable stateful sessions that are needed for real applications.
>
> No. Again, mod_lisp is intended to replace mod_proxy, not to replace
> AServe. Every Lisp application that hide behind Apache through mod_proxy
> should use mod_lisp instead.
Maybe - but IMHO it is a viable alternative to explicitely use mod_proxy
with a fullscale Webserver like AServe, CL-HTTPD (and AFAIK Araneida)
the glue between mod_proxy and another Webserver is simply HTTP - this
makes it _very_ loosely coupled - this *has* benefits.
I think it depends hugely on what you want to do!
"Jochen Schmidt" <···@dataheaven.de> wrote
> Marc Battyani wrote:
> > mod_lisp is essentially a thin, fast and optimized for Lisp mod_proxy.
> The difference is that mod_proxy doesn't depend on a Lisp at it's end
while
> mod_lisp does (by definition and intend).
Sure but
1: we are interested in writing web applications in Lisp IIRC.
2: you can use mod_lisp with other languages if you want.
> >> With mod_proxy it is possible to combine the best from this two worlds.
> > With mod_lisp also as it has been done _exactly_ to do this, sigh...
>
> No - you cannot create a standalone XML-RPC serving Lispapplication.
> (Standalone in the sense of "no external Webserver needed")
> mod_lisp is intended to be the glue between a Lisp and a Webserver
(Apache).
> What I described was the situation where the Webserver already sits *in*
> the Lisp so there's no glue needed.
Do you mean that mod_proxy can be used without Apache here ? I don't
understand that argument.
> > No. Again, mod_lisp is intended to replace mod_proxy, not to replace
> > AServe. Every Lisp application that hide behind Apache through mod_proxy
> > should use mod_lisp instead.
> Maybe - but IMHO it is a viable alternative to explicitely use mod_proxy
> with a fullscale Webserver like AServe, CL-HTTPD (and AFAIK Araneida)
> the glue between mod_proxy and another Webserver is simply HTTP - this
> makes it _very_ loosely coupled - this *has* benefits.
Which ones that you don't have with mod_lisp ?
> I think it depends hugely on what you want to do!
In general yes, but your case no. mod_lisp is intended to be more suited
than mod_proxy for use with AServe, CL-HTTP, Araneida and others _when_ they
are used behind Apache.
Marc
Marc Battyani wrote:
>
> "Jochen Schmidt" <···@dataheaven.de> wrote
>> Marc Battyani wrote:
>
>> > mod_lisp is essentially a thin, fast and optimized for Lisp mod_proxy.
>> The difference is that mod_proxy doesn't depend on a Lisp at it's end
> while
>> mod_lisp does (by definition and intend).
>
> Sure but
> 1: we are interested in writing web applications in Lisp IIRC.
But I don't want necessarily depend on Apache when running my Web-enabled
application - with an embedded AServe I can use my application completely
standalone. But if I *want* to use Apache I have the options to do the
glueing with mod_lisp *or* with mod_proxy. If I use mod_proxy I can easily
use the *same* web enabled application described above, because mod_proxy
and AServe speak the same language (HTTP). If I use mod_lisp my web enabled
application has to speak the mod_lisp protocol - AServe doesn't understand
the mod_lisp protocol so I cannot use it ==> If I use mod_lisp I loose the
capability of my web enabled application to run _without_ an *external*
Webserver.
> 2: you can use mod_lisp with other languages if you want.
sure
>> >> With mod_proxy it is possible to combine the best from this two
>> >> worlds.
>> > With mod_lisp also as it has been done _exactly_ to do this, sigh...
>>
>> No - you cannot create a standalone XML-RPC serving Lispapplication.
>> (Standalone in the sense of "no external Webserver needed")
>> mod_lisp is intended to be the glue between a Lisp and a Webserver
> (Apache).
>> What I described was the situation where the Webserver already sits *in*
>> the Lisp so there's no glue needed.
>
> Do you mean that mod_proxy can be used without Apache here ? I don't
> understand that argument.
No I mean that mod_proxy *cannot* be used without Apache here.
>> > No. Again, mod_lisp is intended to replace mod_proxy, not to replace
>> > AServe. Every Lisp application that hide behind Apache through
>> > mod_proxy should use mod_lisp instead.
>
>> Maybe - but IMHO it is a viable alternative to explicitely use mod_proxy
>> with a fullscale Webserver like AServe, CL-HTTPD (and AFAIK Araneida)
>> the glue between mod_proxy and another Webserver is simply HTTP - this
>> makes it _very_ loosely coupled - this *has* benefits.
>
> Which ones that you don't have with mod_lisp ?
My Webapplication written in Lisp has to speak the mod_lisp protocol - so I
cannot use my web-application with anything other but mod_lisp. AServe,
CL-HTTP and Araneida speak "HTTP" so they can be standalone *and* used with
Apache through mod_proxy (which speaks HTTP too)
>> I think it depends hugely on what you want to do!
>
> In general yes, but your case no. mod_lisp is intended to be more suited
> than mod_proxy for use with AServe, CL-HTTP, Araneida and others _when_
> they are used behind Apache.
??? Why?
ciao,
Jochen
"Jochen Schmidt" <···@dataheaven.de> wrote
> Marc Battyani wrote:
> If I use mod_lisp my web enabled
> application has to speak the mod_lisp protocol - AServe doesn't understand
> the mod_lisp protocol so I cannot use it ==> If I use mod_lisp I loose the
> capability of my web enabled application to run _without_ an *external*
> Webserver.
Ok here we agree.
I don't suggest to use mod_lisp instead of the built-in HTTP front end of
AServe but along it. For example, listening to port 80 or 8000 for HTTP and
port 3000 for mod_lisp. The mod_lisp protocol take less than 30 lines to
implement so it's not that complicated.
> My Webapplication written in Lisp has to speak the mod_lisp protocol - so
I
> cannot use my web-application with anything other but mod_lisp. AServe,
> CL-HTTP and Araneida speak "HTTP" so they can be standalone *and* used
with
> Apache through mod_proxy (which speaks HTTP too)
Ok same answer.
> >> I think it depends hugely on what you want to do!
> >
> > In general yes, but your case no. mod_lisp is intended to be more suited
> > than mod_proxy for use with AServe, CL-HTTP, Araneida and others _when_
> > they are used behind Apache.
>
> ??? Why?
First for performance reasons. The first mod_lisp was based on mod_JServ,
now I have completely re-written it from scratch and I measured an
improvement factor of 40 to 80. (In my test setup, YMMV of course.)
Second because I want to promote Lisp as an industrial strength solution to
write web applications. For this I want to use industry standard solutions
like Apache when they exist. Using an existing Apache-to-whatever mod_xxx
(like mod_proxy, mod_CGI, mod_JServ, etc.) is a good starting point but will
be a dead-end. If the Lisp community needs to add some feature to mod_JServ
for instance, the Java folk have no reason to add it. I often read in this
news group people complaining that Java is more popular than Lisp. So why
can't we at least take some of their ideas when they work. As a language
Java is much less than Lisp but as a marketing success it's much better.
Type "servlet" in www.google.com you get 1910000 replies! (AllegroServe
gives 98, CL-HTTP 7170, mod_lisp 68)
mod_lisp 0.92 was like mod_JServ. Release 2.0 is much better. For the
release 3.0 I plan to add load balancing features (there has been a thread
about scalability of web servers in here recently) I already have ideas for
this but other ideas on the subject are welcome.
IMHO, all these are good reasons for using mod_lisp. Ok some of these are
more political/marketing than technical ones but there are not the least
ones.
Marc
"Marc Battyani" <·············@fractalconcept.com> writes:
> "Jochen Schmidt" <···@dataheaven.de> wrote
> > Marc Battyani wrote:
>
> > If I use mod_lisp my web enabled
> > application has to speak the mod_lisp protocol - AServe doesn't understand
> > the mod_lisp protocol so I cannot use it ==> If I use mod_lisp I loose the
> > capability of my web enabled application to run _without_ an *external*
> > Webserver.
>
> Ok here we agree.
> I don't suggest to use mod_lisp instead of the built-in HTTP front end of
> AServe but along it. For example, listening to port 80 or 8000 for HTTP and
> port 3000 for mod_lisp. The mod_lisp protocol take less than 30 lines to
> implement so it's not that complicated.
But it adds another code-path to the system, which IMHO should be well
motivated before it is being considered. And I haven't seen that
motivation yet.
I think mod_lisp might be a good idea for web applications that don't
contain their own HTTP server, because they are designed to sit behind
an external server, especially if mod_lisp could incorporate features
that hide the intricacies of HTTP/Apache even more from the lisp side.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
From: Jon S Anthony
Subject: Re: why mod_lisp ? (was : Re: Mod_lisp 2.0 released)
Date:
Message-ID: <3B2EAD4A.50D7@synquiry.com>
Pierre R. Mai wrote:
>
> "Marc Battyani" <·············@fractalconcept.com> writes:
>
> > I don't suggest to use mod_lisp instead of the built-in HTTP front end of
> > AServe but along it. For example, listening to port 80 or 8000 for HTTP and
> > port 3000 for mod_lisp. The mod_lisp protocol take less than 30 lines to
> > implement so it's not that complicated.
>
> But it adds another code-path to the system, which IMHO should be well
> motivated before it is being considered. And I haven't seen that
> motivation yet.
>
> I think mod_lisp might be a good idea for web applications that don't
> contain their own HTTP server, because they are designed to sit behind
> an external server, especially if mod_lisp could incorporate features
> that hide the intricacies of HTTP/Apache even more from the lisp side.
That's why there is FastCGI (with mod_fastcgi), which is a (more or
less "standard") socket protocol for several HTTP servers. There are
many library modules for different languages implementing the protocol,
and the CL version is simple, easy and efficient.
/Jon
--
Jon Anthony
Synquiry Technologies, Ltd. Belmont, MA 02478, 617.484.3383
"Nightmares - Ha! The way my life's been going lately,
Who'd notice?" -- Londo Mollari
"Jon S Anthony" <···@synquiry.com> wrote in message
··················@synquiry.com...
> Pierre R. Mai wrote:
> >
> > "Marc Battyani" <·············@fractalconcept.com> writes:
> >
> > > I don't suggest to use mod_lisp instead of the built-in HTTP front end
of
> > > AServe but along it. For example, listening to port 80 or 8000 for
HTTP and
> > > port 3000 for mod_lisp. The mod_lisp protocol take less than 30 lines
to
> > > implement so it's not that complicated.
> >
> > But it adds another code-path to the system, which IMHO should be well
> > motivated before it is being considered. And I haven't seen that
> > motivation yet.
> >
> > I think mod_lisp might be a good idea for web applications that don't
> > contain their own HTTP server, because they are designed to sit behind
> > an external server, especially if mod_lisp could incorporate features
> > that hide the intricacies of HTTP/Apache even more from the lisp side.
>
> That's why there is FastCGI (with mod_fastcgi), which is a (more or
> less "standard") socket protocol for several HTTP servers. There are
> many library modules for different languages implementing the protocol,
> and the CL version is simple, easy and efficient.
Well mod_fastcgi is like mod_jserv, mod_proxy and others, it open and close
a socket from Apache to the application for each request thus limiting
performance. So if you liked mod_fastcgi, you will find mod_lisp easier and
faster.
The comments I've made in my previous post on mod_jserv apply to mod_fastcgi
as well.
Marc
"Pierre R. Mai" <····@acm.org> wrote
> I think mod_lisp might be a good idea for web applications that don't
> contain their own HTTP server, because they are designed to sit behind
> an external server, especially if mod_lisp could incorporate features
> that hide the intricacies of HTTP/Apache even more from the lisp side.
I agree with this but for me mod_lisp is useful as soon as you are behind
Apache.
Marc
Jochen Schmidt <···@dataheaven.de> writes:
> I don't really understand why this is understood as a so big problem...
> Is including SSL with Lisp *so* difficult that it _really_ needs such a
> fragile and in cryptographic sight "questionable" thing?
Btw, I just responded to this saying why I like the Apache approach, but let
me say I'd be very happy to see a portable SSL layer for Lisp. (I'm not sure
I'd use it for the web, but I can think of other things I might use it for.)
Kent M Pitman wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>
>> I don't really understand why this is understood as a so big problem...
>> Is including SSL with Lisp *so* difficult that it _really_ needs such a
>> fragile and in cryptographic sight "questionable" thing?
>
> Btw, I just responded to this saying why I like the Apache approach, but
> let
> me say I'd be very happy to see a portable SSL layer for Lisp. (I'm not
> sure I'd use it for the web, but I can think of other things I might use
> it for.)
I had no problems with the Apache approach - I only don't like the idea of
using hacks like stunnel instead of integrated SSL support.
The TCP support of the existing implementations has not to be changed to
add SSL. SSL works by opening a conventional TCP socket and then using that
for SSL. For the ACL way of doing this, this would mean that you open your
socket-stream the usual way and then call e.g:
(make-ssl-client-stream socket-stream)
to get a stream-object that is then used for SSL I/O.
(You should not send/receive any I/O from the former socket-stream after
that!)
The stream-object that is returned by MAKE-SSL-CLIENT-STREAM could be
implemented with GRAY-STREAMS so that it uses the foreign-functions
SSL_write and SSL_read for I/O. SSL_write and SSL_read are the same as
read() and write() in C they "only" add all SSL protocol stuff.
ciao,
Jochen
>>>>> "jochen" == Jochen Schmidt <···@dataheaven.de> writes:
jochen> I had no problems with the Apache approach - I only don't
jochen> like the idea of using hacks like stunnel instead of
jochen> integrated SSL support.
Just how much of a hack to you think it is? It seems pretty simple
and straight-forward. God knows how many enterprise servers and
firewalls out there are playing similar port-forwarding games.
dave
David Bakhash wrote:
>>>>>> "jochen" == Jochen Schmidt <···@dataheaven.de> writes:
>
> jochen> I had no problems with the Apache approach - I only don't
> jochen> like the idea of using hacks like stunnel instead of
> jochen> integrated SSL support.
>
> Just how much of a hack to you think it is? It seems pretty simple
> and straight-forward. God knows how many enterprise servers and
> firewalls out there are playing similar port-forwarding games.
The problem that is inherent with such port-forwarding solutions is that
you have to ensure that nobody can't sniff between this connection.
Another thing is that it needs a considerable amount of administration.
I'm not usre if it is easy usable on Windows...
I know that there this kind of things are used alot - but that doesn't mean
that this is either the right thing or a good thing at all.
The most "professional Software developers" I met have NIL experience on
only the basics of cryptography. I know some "professional Software
developers" that wanted to do secure transmission of credit-card card
information by zipping the data and inverting a particular bit!!!
STunnel & Co. is not *that* bad but it is not comparable to integrated SSL
support. IMHO it is obvious what way to go if one says "Integrate OpenSSL
to Lisp" and another one says "Use stunnel forwarding if you want to do SSL"
I repeat my offering - if there is someone from MCL, CLISP and CMUCL that
is interested in creating integrated SSL support for their Lisp, then
please contact me. I do the work _now_ for LispWorks (have not got any
answer fom Xanalys yet) I won't do the FFI work for all - CLISP, CMUCL,
MCL ...
ciao,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
> The problem that is inherent with such port-forwarding solutions is that
> you have to ensure that nobody can't sniff between this connection.
I would be very very surprised to hear that sniffing from elsewhere on
the network would show data on connections bound to loopback sockets.
That's a bug in your OS and you should take it up with the OS vendor.
Of course, if you're root on the local machine you can sniff the
loopback interface if you want to, but at that point you have other
avenues open to you anyway, so I don't rate that as an exposure.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
>
> I would be very very surprised to hear that sniffing from elsewhere on
> the network would show data on connections bound to loopback sockets.
> That's a bug in your OS and you should take it up with the OS vendor.
More to the point, if you have enemies able to sniff connections on
your private network you are in deep shit for a lot of other reasons.
I don't think anyone is suggesting port-forwarding proxies over the
open internet.
--tim
Tim Bradshaw wrote:
> Daniel Barlow <···@telent.net> writes:
>
>>
>> I would be very very surprised to hear that sniffing from elsewhere on
>> the network would show data on connections bound to loopback sockets.
>> That's a bug in your OS and you should take it up with the OS vendor.
>
> More to the point, if you have enemies able to sniff connections on
> your private network you are in deep shit for a lot of other reasons.
I often worked in environments where other people had root-access to the
machines I worked on - I think it should be made not so easy for them to do
a simple connection sniff!!!
> I don't think anyone is suggesting port-forwarding proxies over the
> open internet.
Forwarding over loopback sockets is worse enough - Is it *so difficult to
understand that the use of SSL is drastically reduced if you make it *so*
easy to get the plaintext?
This discussion does *not* have anything to do with "the big enemy"
(whoever that is).
Even average administrators are able to sniff your LAN and local machines.
So please don't tell me that the security of forwarding solutions is
essentially equal to direct solutions - this is nonsense.
ciao,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
>
> I often worked in environments where other people had root-access to the
> machines I worked on - I think it should be made not so easy for them to do
> a simple connection sniff!!!
These same people have all your private keys, or hadn't you noticed that?
--tim
Tim Bradshaw wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>
>>
>> I often worked in environments where other people had root-access to the
>> machines I worked on - I think it should be made not so easy for them to
>> do a simple connection sniff!!!
>
> These same people have all your private keys, or hadn't you noticed that?
Sounds a bit insulting - but probably was not intented to be so... (a
smiley would have helped...)
The keys are stored encrypted, and are encrypted in a non-swappable
memory-section. So they have to get me typing the passprhase. This *is*
possible (not *too* difficult) if they have access to the machine I type
on. If I write a little program that creates a random session key and
exchanges the key by DH with a machine I type my password in where the
admin has *no* root access (and therefore is unable to sniff the keys) then
I enhance the security again to inspecting process memory.
This is one reason why you have the password input callbacks in OpenSSL...
Have you lieing your secret keys on places others have access to -
unencrypted? whoa....
ciao,
Jochen
Tim Bradshaw <···@tfeb.org> writes:
> More to the point, if you have enemies able to sniff connections on
> your private network you are in deep shit for a lot of other reasons.
I don't know about all this enemies stuff, but how difficult is it to
imagine a situation where you have maybe one or two applications that
have sensitive data communicating across an internal network common to
those sensitive applications as well as some less important (so
probably less secure) applications. Even if those applications are
secure, maybe only some parts of the company should have access to
these data.
···@conquest.OCF.Berkeley.EDU (Thomas F. Burdick) writes:
> I don't know about all this enemies stuff, but how difficult is it to
> imagine a situation where you have maybe one or two applications that
> have sensitive data communicating across an internal network common to
> those sensitive applications as well as some less important (so
> probably less secure) applications. Even if those applications are
> secure, maybe only some parts of the company should have access to
> these data.
I think the common approach to this is by network topology and
encryption. You have your little cluster of machines which want to
talk together on a bit of network which is not accessible to the world
(by `the world' I mean the rest of the company), and they may talk to
some other bit of secure network over an encrypted connection.
There's a couple of reasons why this is a good way to do things:
If the data is valuable to you then arranging network topology is
cheap compared to it (this is true even for pretty small networks:
lots of things are expensive compared to hardware now!).
If reliability & availability is valuable to you then you typically
will think very hard before patching the machines: a destabilising
security fix (far from unheard-of) on a machine running a
mission-critical application is *not* something you want to be
responsible for as a systems person (I'm really a sysadmin, I just
play at Lisp). For some applications the downtime to install a patch
is hard to get. Very often the administrative pain of making changes
discourages them. So you bury the machines behind layers of routers
and firewalls so you don't need to worry about being bang up to
date. (An example of this is machines I work with at the moment (not
in quite this scenario): it usually takes at least 6 weeks to get a
change in.)
If performance matters then you may not want to pay the cost of
encryption (things like SANs over huge-bandwidth network for
instance).
None of this is meant to imply I don't think native-SSL is a good
thing or that your scenario cannot arise. I *do* think it is a good
thing: I'm just describing how things get done in my world.
I think this is kind of offtopic by now and I don't really want to
encourage topic drift, so I'll shut up unless something really
compelling comes up.
--tim
Daniel Barlow wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>
>> The problem that is inherent with such port-forwarding solutions is that
>> you have to ensure that nobody can't sniff between this connection.
>
> I would be very very surprised to hear that sniffing from elsewhere on
> the network would show data on connections bound to loopback sockets.
> That's a bug in your OS and you should take it up with the OS vendor.
>
> Of course, if you're root on the local machine you can sniff the
> loopback interface if you want to, but at that point you have other
> avenues open to you anyway, so I don't rate that as an exposure.
The bad thing is not how "super difficult" it is to sniff loopback sockets,
but the fact that sniffing the sockets is *much* easier than to hack RSA
RC4 or to inspect the running image of the process.
It is ridicuous that an admin of a machine is *so* trivially able to read
your encrypted connection. You _reduce_ the *whole* strength of the
cryptographic process on the difficulty of a local connection sniff (!).
In the times of trojans that manage to get root access it is IMHO important
to make it as difficult as possible - and live-inspecting the process ram
for the plain data is *much* more difficult than loopback sniffing.
Do you *really* think that this security argumentation is futile and
unimportant? Do you really think that this dreck doesn't reduce the
security much?
Cryptography is now a occupation I have for several years - and I'm
everytime really astonished how most people find the basic rules of
cryptography and information theory rather unimportant...
ciao,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
>
> The bad thing is not how "super difficult" it is to sniff loopback sockets,
> but the fact that sniffing the sockets is *much* easier than to hack RSA
> RC4 or to inspect the running image of the process.
> It is ridicuous that an admin of a machine is *so* trivially able to read
> your encrypted connection. You _reduce_ the *whole* strength of the
> cryptographic process on the difficulty of a local connection sniff (!).
IF you have someone on your machine, with root access so they can
sniff the loopback sockets, the *least* of your problems is that they
can sniff them. You seem to be arguing that it's hard to sniff stuff
in RAM: yes, it is, but if you are doing anything interesting you are
writing the stuff to non-volatile storage, and it's easy to look at
that (and if you are encrypting it, where is the encrupton key coming
from?).
> Do you *really* think that this security argumentation is futile and
> unimportant? Do you really think that this dreck doesn't reduce the
> security much?
>
yes. I think it's a complete waste of time. You have other, much
more serious, problems if you have an intruder with root access on
your machine. Really, you do.
--tim
> > Do you *really* think that this security argumentation is futile and
> > unimportant? Do you really think that this dreck doesn't reduce the
> > security much?
> >
>
> yes. I think it's a complete waste of time. You have other, much
> more serious, problems if you have an intruder with root access on
> your machine. Really, you do.
Just because a native SSL implementation might be a waste of time in
some circumstances doesn't make it so in others. Port forwarding is
presumably sometimes a reasonable tradeoff, but not always so.
Gregm
Greg Menke <··········@mindspring.com> writes:
> > > Do you *really* think that this security argumentation is futile and
> > > unimportant? Do you really think that this dreck doesn't reduce the
> > > security much?
> > >
> >
> > yes. I think it's a complete waste of time. You have other, much
> > more serious, problems if you have an intruder with root access on
> > your machine. Really, you do.
>
>
> Just because a native SSL implementation might be a waste of time in
> some circumstances doesn't make it so in others. Port forwarding is
> presumably sometimes a reasonable tradeoff, but not always so.
>
Yes, I'm sorry to have sounded like I meant that. What I was trying
to say was *not* that a native SSL implementation was a waste of time,
but that trying to make a system secure where someone with complete
power over the machine is not trusted is a waste of time.
Apart from anything else port-forwarding is a more complex solution
and thus has more points of failure, so a native solution is
preferable in that respect, if not others.
--tim
Tim Bradshaw wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>
>>
>> The bad thing is not how "super difficult" it is to sniff loopback
>> sockets, but the fact that sniffing the sockets is *much* easier than to
>> hack RSA RC4 or to inspect the running image of the process.
>> It is ridicuous that an admin of a machine is *so* trivially able to read
>> your encrypted connection. You _reduce_ the *whole* strength of the
>> cryptographic process on the difficulty of a local connection sniff (!).
>
> IF you have someone on your machine, with root access so they can
> sniff the loopback sockets, the *least* of your problems is that they
> can sniff them. You seem to be arguing that it's hard to sniff stuff
> in RAM: yes, it is, but if you are doing anything interesting you are
> writing the stuff to non-volatile storage, and it's easy to look at
> that (and if you are encrypting it, where is the encrupton key coming
> from?).
Possible solution described in the other thread.
>> Do you *really* think that this security argumentation is futile and
>> unimportant? Do you really think that this dreck doesn't reduce the
>> security much?
>>
>
> yes. I think it's a complete waste of time. You have other, much
> more serious, problems if you have an intruder with root access on
> your machine. Really, you do.
Oh nice to know that you think creating a integrated SSL solution would be
a waste of time...
Oh boy - I really begin to think seriously why I should do this...
The number of people that tell me how useless my effort is and how much
more important things would be there to *volunteer* is increasing at a
rate that now begins to significantly reduce my mood to "volunteer" for
anything more...
saddened,
Jochen Schmidt
Jochen Schmidt <···@dataheaven.de> writes:
>
> Oh nice to know that you think creating a integrated SSL solution would be
> a waste of time...
>
I didn't mean that: I'm sorry if I sounded like that.
What I meant was that trying to protect against a situation where
someone you do not implicitly trust has root access to a traditional
Unix[*] box is a complete waste of time. Unix is just not secure that
way: you need to make sure that that never happens.
--tim
[*] Traditional Unix is meant to exclude things like the various
trusted-x Unices which have a slightly less rudimentary security
model.
Tim Bradshaw wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>
>>
>> Oh nice to know that you think creating a integrated SSL solution would
>> be a waste of time...
>>
>
> I didn't mean that: I'm sorry if I sounded like that.
>
> What I meant was that trying to protect against a situation where
> someone you do not implicitly trust has root access to a traditional
> Unix[*] box is a complete waste of time. Unix is just not secure that
> way: you need to make sure that that never happens.
Ok taken,
The problem was probably furthermore that I simply argued why
port-forwarding solutions are inferior to native ones (As I was asked).
I think it is obvious that you _could_ do "all" as root - but not every
admin is able to do "all" but I know no serious admin that is not abe to
sniff a connection.
Discussing this topics reaches often points were it gets really unrealistic
- IMHO it is much easier for your enemy to visit you and point a shotgun to
your, or your Girlfriends (or childrens) face(s) if you really have some
information that is *so* important.
Encryption, particularily seen on a local server is not much more than
using a envelope instead of a postcard - if someone wants to read your post
then he can easily manage to do so - but if you use a postcard it is *so*
easy to read it that practically no effort is needed.
I still think that the arguments are valid _particularily_ in a more secure
environment with a more finegrained notion of e. g. "root".
Besides of our "misunderstanding" I still think that there's a strange
amount of discouragement to volunteer in our comunity. Some of the things I
think that lead to this are:
- if someone volunteers there are some people that think that he/she wants
generally to "volunteer" - some kind of gratis worker that can be used
to do what they think should be done. So they say things like "But X, and
Y are much more important to work on - you should do that..." where X and
Y would have _nothing_ in common (but lisp) with what the volunteer
wanted to contribute.
- Volunteers get amazingly little help and response from the comunity
- If you simply ask e. g. what kind of API would be prefered, a discussion
is started if this question is a valid one instead of simply asking the
question.
- Theres _very_ little tolerance between users of different lisp-systems
(somewhat of a "Let them do what they want - we do it so!" attitude.
- If someone has an idea on how to do something better - the first what is
asked is "do you volunteer"? This is particularily strange when it comes
to the common opinion on "people demanding gratis tools". It is equally
bad style to demand from someone to do gratis work.
Most of this things are not inherently bad - but all lead IMHO to the
situation where people that are _willing_ to volunteer are driven away.
ciao,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
> Discussing this topics reaches often points were it gets really unrealistic
> - IMHO it is much easier for your enemy to visit you and point a shotgun to
> your, or your Girlfriends (or childrens) face(s) if you really have some
> information that is *so* important.
yes, I agree with this. I think it's very important that people
evaluate risk for this sort of thing pretty carefully. Lots of people
are using billion-bit encryption with physically-insecure machines:
chucking a brick through a window and walking off with the disk array
is a pretty good way of defeating this.
Indeed my point was really meant to be about risk - if the server is
not secure I think (I may be wrong, of course) that for most purposes
encryption will not help.
> I still think that the arguments are valid _particularily_ in a more secure
> environment with a more finegrained notion of e. g. "root".
Yes. RBAC or sudo are both things that people use to try and make
root not so catastrophically bad, there are probably lots of others.
I certainly did not mean to discourage anyone from implementing
anything, and I'm sorry if my comments were taken that way. For our
applications we probaby would not want native SSL (we'd do some proxy
thing), but that does *not* mean it's not useful.
--tim
On Tue, 19 Jun 2001, Jochen Schmidt wrote:
> Besides of our "misunderstanding" I still think that there's a strange
> amount of discouragement to volunteer in our comunity. Some of the things I
Welcome to the party :)
> think that lead to this are:
>
> - if someone volunteers there are some people that think that he/she wants
> generally to "volunteer" - some kind of gratis worker that can be used
> to do what they think should be done. So they say things like "But X, and
> Y are much more important to work on - you should do that..." where X and
> Y would have _nothing_ in common (but lisp) with what the volunteer
> wanted to contribute.
You should ignore advice like that.
> - Volunteers get amazingly little help and response from the comunity
Yup, until a certain critical mass is reached.
> - If you simply ask e. g. what kind of API would be prefered, a discussion
> is started if this question is a valid one instead of simply asking the
> question.
I'm not sure what you expect with regards to Usenet. It's much more
productive to just implement the API you have in mind, bang it a bit, let
others bang on it too, and let it evolve than to try to do
design-by-committee with a cast of thousands. Not many competent people
have the time or inclination to give feedback on a design that may or may
not ever get implemented usefully.
> - Theres _very_ little tolerance between users of different lisp-systems
> (somewhat of a "Let them do what they want - we do it so!" attitude.
Discussions about Lisp systems that I don't use are off-topic :)
Seriously, the situation in comp.lang.lisp is a out of the ordinary: many
of the questions that come up here would be shouted down in comp.lang.c or
comp.lang.c++ as being operating-system or implementation specific and not
relevant. The Lisp community history and dynamics are a bit different; I
think discussion of and interest in different implementations is fairly
high here. But you can't expect people to get all fired up about stuff
they won't use.
> - If someone has an idea on how to do something better - the first what is
> asked is "do you volunteer"? This is particularily strange when it comes
> to the common opinion on "people demanding gratis tools". It is equally
> bad style to demand from someone to do gratis work.
There's a lot of background noise on Usenet; this can be an effective
filter i.e., if you can't do the work, you're not qualified to talk about
it.
"Volunteering" and "sharing" have a lot in common, but they are not the
same thing. Working on free software is very different from
volunteering at the local soup kitchen. I'm not sure that the altruism
implied by pure volunteerism is going to get you very far in the free
software world unless you have a very strong personality.
By the way, your own contributions so far are great, though I haven't had
the time to check them out and won't make use of the AServe stuff because
I don't use LispWorks :):):)
Tim
Tim Moore wrote:
> On Tue, 19 Jun 2001, Jochen Schmidt wrote:
>> Besides of our "misunderstanding" I still think that there's a strange
>> amount of discouragement to volunteer in our comunity. Some of the things
>> I
> Welcome to the party :)
;-)
>> think that lead to this are:
>>
>> - if someone volunteers there are some people that think that he/she
>> wants
>> generally to "volunteer" - some kind of gratis worker that can be used
>> to do what they think should be done. So they say things like "But X,
>> and Y are much more important to work on - you should do that..." where
>> X and Y would have _nothing_ in common (but lisp) with what the
>> volunteer wanted to contribute.
> You should ignore advice like that.
Yes _I_ do it - but I everytime feel a bit depressed if it happens to me or
if I see that others are driven away because of this. Probably a lot more
people would volunteer if the support and help would be at least a little
bit more than the general opposition.
>> - Volunteers get amazingly little help and response from the comunity
> Yup, until a certain critical mass is reached.
Yes - and the last example I saw was the idea of Wade to unify some things
as a comunity. I think through the very nice and fantastic attitudes of
some people he will think a bit more before offering any (IMHO good!) ideas
to the comunity. What most people did not know was that we was already in
contact and he was one of the few people that already have and wanted to
offer their time for the comunity. I hope Wade, that you're not discouraged
through this experience!
>> - If you simply ask e. g. what kind of API would be prefered, a
>> discussion
>> is started if this question is a valid one instead of simply asking
>> the question.
>
> I'm not sure what you expect with regards to Usenet. It's much more
> productive to just implement the API you have in mind, bang it a bit, let
> others bang on it too, and let it evolve than to try to do
> design-by-committee with a cast of thousands. Not many competent people
> have the time or inclination to give feedback on a design that may or may
> not ever get implemented usefully.
I did certainly _not_ expected to standardize an API here in Usenet, but I
hoped to here at least some opinions on what different people like and not
like with the actual interfaces. Who knows - probably more than the half of
the people use CLOCC-Port (I dont' think so but as an example) and we
simply do not know it???
perhaps there are a significant amount of people that only dislike
CLOCC-Port because somthing is done they way it is now (e. g. using
deftypes and defuns instead of classes and methods as someone said some
time ago)
I_really_ did not expected that the peoplebegin to standardize the API here
in comp.lang.lisp but I hoped to get some ideas, help and *constructive*
critique. But nothing of that seems to be possible...
>> - Theres _very_ little tolerance between users of different lisp-systems
>> (somewhat of a "Let them do what they want - we do it so!" attitude.
>
> Discussions about Lisp systems that I don't use are off-topic :)
> Seriously, the situation in comp.lang.lisp is a out of the ordinary: many
> of the questions that come up here would be shouted down in comp.lang.c or
> comp.lang.c++ as being operating-system or implementation specific and not
> relevant. The Lisp community history and dynamics are a bit different; I
> think discussion of and interest in different implementations is fairly
> high here. But you can't expect people to get all fired up about stuff
> they won't use.
I meant that we have some groups that work - within their little world -
rather efficiently together. In the public this are at least the CLISP
people and the CMUCL people. CLOCC seems to me much like a CLISP thing and
cCLan seems to be _rather_ Unix/CMUCL centric. I understand and respect
that you could not expect people to work on stuff they do not use - but I
think they should try to get in contact with people that _would need the
stuff. For example AServe and the SSL stuff now - I've not the time to do
all the work alone to get it working on more than LispWorks - but I'm
willing to communicate and help others that want AServe and SSL on e.g
CLISP, CMUCL, MCL and Corman Lisp. Chris Double and I said that we want to
work together so that there is a "portable AServe" instead of 5 different
ones. Eric Marsden contacted me already and he seems to have interest in
helping getting SSL done for CMUCL. Wade offered his help to work with me
on the SSL stuff for LispWorks.
Probably I'm a rather crazy guy - I have a strange demand for "portability"
and "crossplatform-capabilities" for all things I do.
>> - If someone has an idea on how to do something better - the first what
>> is
>> asked is "do you volunteer"? This is particularily strange when it
>> comes to the common opinion on "people demanding gratis tools". It is
>> equally bad style to demand from someone to do gratis work.
>
> There's a lot of background noise on Usenet; this can be an effective
> filter i.e., if you can't do the work, you're not qualified to talk about
> it.
This says implicitely that either the people that offer ideas want to harm
someone and therefore have to pay for it, or that nobody here is interested
in discussing new ideas.
I don't think that you have to be a volunteer to be qualified to talk here.
E. g. Kent M. Pitman very often gives amazingly insightful ideas to the
comunity but nobody demands of him that he himself should volunteer on
realizing his ideas. I find it often _very_ valuable to hear the sometimes
(on the first glance) strange opinions and ideas of newbies - this is a
basic evolutionary rule.
> "Volunteering" and "sharing" have a lot in common, but they are not the
> same thing. Working on free software is very different from
> volunteering at the local soup kitchen. I'm not sure that the altruism
> implied by pure volunteerism is going to get you very far in the free
> software world unless you have a very strong personality.
Yes that's right.
> By the way, your own contributions so far are great, though I haven't had
> the time to check them out and won't make use of the AServe stuff because
> I don't use LispWorks :):):)
Thanks :-)
Btw. the AServe port should be _rather_ portable. The main activites I've
done was to remove ACL specific stuff and replace it with portable stuff.
There _should_ be no parts out of the ACL-COMPAT modules that depend on
LispWorks...
the start would be to implement the ACL-COMPAT stuff for e. g. CMUCL. I've
begun this but stopped at the MP stuff. AServe make heavy use of
RUN-REASONS which are available in ACL and LispWorks MP package but not in
CMUCL. this would mean either to enhance CMUCLs MP with RUN-REASONS or
change many parts in AServe to do it differently.
This should not be much work - but I'm rather busy ...
I hoped that someone from CMUCL would contact me helping out a bit (giving
advice on this MP stuff and helping developing the ACL-Sockets wrapper for
CMUCL)
ciao,
Jochen
>
> Yes - and the last example I saw was the idea of Wade to unify some things
> as a comunity. I think through the very nice and fantastic attitudes of
> some people he will think a bit more before offering any (IMHO good!)
ideas
> to the comunity. What most people did not know was that we was already in
> contact and he was one of the few people that already have and wanted to
> offer their time for the comunity. I hope Wade, that you're not
discouraged
> through this experience!
Well, no. I am still endeavouring to code a pure CL SSL however. I have
most of the basic handshake stuff thought out and some initial code with the
ideas. Just getting to the cryto-stuff, like MAC (whatever that is) and how
to exchange and encrypt data. I thought it was fairly straight forward, but
of course its not. Even though this effort probably will not be used I
would like to relate my happiness at seeing how well CL is thought out
concerning protocols/buffers (arrays). I have primarily programmed
protocols OSI/TCP/Data Acquisition for my professional programming career.
Whoever thought out all the array/sequence functionality knew what they were
doing! Hats off.
I looked at the OpenSSL C interface in hopes of wrapping it in a stream.
Cannot seem to find any good examples of utilizing it though. Its buried in
the test code that comes with OpenSSL.
As for unification, still have not changed my mind. The primary discussion
of the API socket basically boils down to, it does not matter, and if it
does it is not much code. Unification will not affect that area what so
ever.
Another area I mentioned was FFI. Ideally I would like to see a unified C
header parsing tool.
Wade
Wade Humeniuk wrote:
>>
>> Yes - and the last example I saw was the idea of Wade to unify some
>> things as a comunity. I think through the very nice and fantastic
>> attitudes of some people he will think a bit more before offering any
>> (IMHO good!)
> ideas
>> to the comunity. What most people did not know was that we was already in
>> contact and he was one of the few people that already have and wanted to
>> offer their time for the comunity. I hope Wade, that you're not
> discouraged
>> through this experience!
>
> Well, no. I am still endeavouring to code a pure CL SSL however. I have
> most of the basic handshake stuff thought out and some initial code with
> the
> ideas. Just getting to the cryto-stuff, like MAC (whatever that is) and
"Message Authentication Code". Basically this is a hashvalue created by a
cryptographic hash-algorithm like e. g. MD5, SHA or RIPEMD. To do a bit
better there are some seeding schemes.
> I looked at the OpenSSL C interface in hopes of wrapping it in a stream.
> Cannot seem to find any good examples of utilizing it though. Its buried
> in the test code that comes with OpenSSL.
I've sent you some code and info...
> As for unification, still have not changed my mind. The primary
> discussion of the API socket basically boils down to, it does not matter,
> and if it
> does it is not much code. Unification will not affect that area what so
> ever.
>
> Another area I mentioned was FFI. Ideally I would like to see a unified C
> header parsing tool.
There is cparse that works for CMUCL but AFAIK is retargetable and the
alternative is SWIG.
ciao,
Jochen
Jochen Schmidt wrote:
>>Wade:
>> Another area I mentioned was FFI. Ideally I would like to see a unified C
>> header parsing tool.
>
>There is cparse that works for CMUCL but AFAIK is retargetable and the
>alternative is SWIG.
SWIG is a waste of time, imho.
cparse has the CMUCL problem. it is too "good" to be able to be easily
retargetted to easier and simplier lisps. but it is the best so far we
have into this direction.
(compared to ffigen, Header2Scheme and the corman and acl header
parsers)
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
······@x-ray.at (Reini Urban) writes:
> SWIG is a waste of time, imho.
What's the problem with it, in your opinion?
(My impression last time I played with it was that it was unlikely to
be all that good a fit to CL - I wish I could still remember why I
concluded that - but that the "annotations" it encouraged people to
put in their header files for easier parsing were probably a good
thing and might be useful for some hypothetical CL tool to understand)
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow wrote:
>······@x-ray.at (Reini Urban) writes:
>
>> SWIG is a waste of time, imho.
>
>What's the problem with it, in your opinion?
>
>(My impression last time I played with it was that it was unlikely to
>be all that good a fit to CL - I wish I could still remember why I
>concluded that - but that the "annotations" it encouraged people to
>put in their header files for easier parsing were probably a good
>thing and might be useful for some hypothetical CL tool to understand)
I checked it also long time ago for various projects. I even did some
perl XS projects in SWIG (some compgeom modules which I needed in perl
and AutoLISP), but then it was much easier to do it manually for perl
and lisp, once I undertood the internals. The vector and hash mappings
are terribly complicated. I rewrote it in raw XS (perl) and C
(autolisp), which was faster to write and easier to maintain.
With a hypothetical SWIG as lisp app it would have been much easier to
customize and retarget.
CL's have much more options to support, vector and hash-wise, so it
would be a major effort. Not worth imho.
The guile binding is so different to perl and python and I don't have
the impression that it was actually useful. I started to write the SWIG
autolisp language extension, but stopped somewhere in between.
Maintaining the two bindings manually was easier, and fitted better to
each languages strengths.
But as you, I cannot remember my exact arguments then also.
I prefer CLISP's and gambit's FFI approaches to this, though I didn't
actually code in those two yet.
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
On Fri, 22 Jun 2001, Reini Urban wrote:
> SWIG is a waste of time, imho.
>
> cparse has the CMUCL problem. it is too "good" to be able to be easily
> retargetted to easier and simplier lisps. but it is the best so far we
> have into this direction.
"Too good" is not a criticism I would have expected of cparse :) Could
you expand a bit on what you mean by that? Do you mean that it's too hard
to generate function and type definitions for simpler FFIs? My intent was
to allow the FFI generator (human or code) to use as much or little of the
C parse tree as is useful. Or do you mean that the code itself is too
hard to retarget for whatever reason?
> (compared to ffigen, Header2Scheme and the corman and acl header
> parsers)
Tim
Tim Moore wrote:
>On Fri, 22 Jun 2001, Reini Urban wrote:
>> SWIG is a waste of time, imho.
I found this old article of mine about swig:
http://xarch.tu-graz.ac.at/autocad/lisp/ffis.html#swig
>> cparse has the CMUCL problem. it is too "good" to be able to be easily
>> retargetted to easier and simplier lisps. but it is the best so far we
>> have into this direction.
>"Too good" is not a criticism I would have expected of cparse :) Could
>you expand a bit on what you mean by that? Do you mean that it's too hard
>to generate function and type definitions for simpler FFIs?
It reminds me on the free libffi, the c library, in comparison to
haible's gnu ffcall library (also c).
cparse supports really all options and problems to fit to cmucl's alien,
which is very good in types.
but for the beginning I whished I could understand a simplier approach.
the scheme c parsers generate simplier code because they have much
simplier (and limited) interfaces.
in my ffi's I only need int32, double and strings and only sometimes
aggregate types (union, vector, structs), because C can only do this.
>My intent was to allow the FFI generator (human or code) to use as much or little of the
>C parse tree as is useful. Or do you mean that the code itself is too
>hard to retarget for whatever reason?
That was my intention when I looked at it the first time. Now that I
understand more it looks better. But I haven't used it yet.
>> (compared to ffigen, Header2Scheme and the corman and acl header
>> parsers)
This was obviously wrong. They are specialized tools, yours is very
generic and clean. A clisp, acl and lw class would be fine, as proof of
concept :)
Everybody would love it, if it would work good enough...
--
Reini Urban
http://xarch.tu-graz.ac.at/autocad/news/faq/autolisp.html
On Tue, 19 Jun 2001, Jochen Schmidt wrote:
> Tim Moore wrote:
> >> - Volunteers get amazingly little help and response from the comunity
> > Yup, until a certain critical mass is reached.
>
> Yes - and the last example I saw was the idea of Wade to unify some things
> as a comunity. I think through the very nice and fantastic attitudes of
> some people he will think a bit more before offering any (IMHO good!) ideas
> to the comunity. What most people did not know was that we was already in
> contact and he was one of the few people that already have and wanted to
> offer their time for the comunity. I hope Wade, that you're not discouraged
> through this experience!
My internal response to Wade's idea was "Who the hell is Wade? I don't
know him from Adam." Now, this is grossly unfair, of course, but prestige
and name recognition have a lot to do with whether or not people take you
seriously. For example, in this group, if Erik or KMP had proposed such a
thing, I would have to take it more seriously. Alternatively, if a
(similar but stupid) idea were presented like so: "I have an idea for
unifying the interface to IDENTD in CL; check out my sample implementation
at http://foo.bar.org which already works in CMUCL, ACL and CLISP" then I
would have to take that seriously too. Otherwise, if you come out of the
blue and propose that there ought to be a solution to a hard, expensive
problem, you're going to get shot down.
(This is not to say that I shouldn't know Wade's name, just that I don't.)
> >> - Theres _very_ little tolerance between users of different lisp-systems
> >> (somewhat of a "Let them do what they want - we do it so!" attitude.
> >
> > Discussions about Lisp systems that I don't use are off-topic :)
> I meant that we have some groups that work - within their little world -
> rather efficiently together. In the public this are at least the CLISP
> people and the CMUCL people. CLOCC seems to me much like a CLISP thing and
> cCLan seems to be _rather_ Unix/CMUCL centric. I understand and respect
I don't think it's as grim as you paint it -- I see bug reports from the
main CLOCC maintainer on the CMUCL mailing lists fairly often, and CLOCC
works well on CMUCL last time I checked. cCLan *just* got started, at
least one of its main shakers is heavily involved in SBCL, it's using
Debian packages as a prototype... so what do you expect?
> >> - If someone has an idea on how to do something better - the first what
> >> is
> >> asked is "do you volunteer"? This is particularily strange when it
> >> comes to the common opinion on "people demanding gratis tools". It is
> >> equally bad style to demand from someone to do gratis work.
> >
> > There's a lot of background noise on Usenet; this can be an effective
> > filter i.e., if you can't do the work, you're not qualified to talk about
> > it.
>
> This says implicitely that either the people that offer ideas want to harm
> someone and therefore have to pay for it, or that nobody here is interested
> in discussing new ideas.
I don't think it's that extreme, it's more an explicit statement of "if
you want a feature, you'll have to implement it yourself." And that's
just how it is, of course, in the free software world: no one's paying the
implementors or otherwise coercing them to do any particular thing and
rarely are they casting around for ideas, looking for something to do.
This goes back to the idea that some people will take advantage of any
available free labor: the "patches welcome" comeback is often a reaction
to that perceived assumption.
> I don't think that you have to be a volunteer to be qualified to talk here.
> E. g. Kent M. Pitman very often gives amazingly insightful ideas to the
> comunity but nobody demands of him that he himself should volunteer on
> realizing his ideas. I find it often _very_ valuable to hear the sometimes
> (on the first glance) strange opinions and ideas of newbies - this is a
> basic evolutionary rule.
Well yeah, but kmp has paid his dues big time, so there will be a
preconceived idea that he is worth listening to, whether or not that is
actually the case. (insert smiley here)
Tim
Jochen Schmidt <···@dataheaven.de> writes:
> I_really_ did not expected that the peoplebegin to standardize the API here
> in comp.lang.lisp but I hoped to get some ideas, help and *constructive*
> critique. But nothing of that seems to be possible...
>
I think there's something strange about usenet in particular which
makes this not work. All the things I've ever done which have
involved agreeing on interfaces &c have worked by more-or-less private
mailing lists (typically at least of the
you-can't-send-mail-unless-you-subscribe kind). I don't know why they
should work better, or indeed if they still do (all this was some time
ago).
I think one thing that obviously makes mailing lists better is this: I
wouldn't subscribe to a standard-sockaets-api list for instance - not
because I am uninterested or think it is not a good thing to do, but
because I have no time to usefully contribute. But I do read c.l.l.
So you get a lot of people, like me, who are happy, perhaps, to offer
opinions but not to offer code (actually I've tried not to offer
opinions about what would be desirable technically, but you see what I
mean).
It would be interesting to know whether other languages/systems get
stuff done by usenet or whether it all happens on mailing lists: I
suspect the latter, but I don't know.
--tim
Jochen Schmidt <···@dataheaven.de> writes:
> I did certainly _not_ expected to standardize an API here in Usenet, but I
> hoped to here at least some opinions on what different people like and not
> like with the actual interfaces. Who knows - probably more than the half of
I think it unlikely that anyone has used enough different interfaces
to make a useful comparative review - at least, if anyone had, I'd
expect they would have produced something along the lines of Martin
Cracauer's web page comparing MP APIs.
I can tell you about the evaluation process I went through a couple of
years ago with the CMUCL sockets API (the stuff in internet.lisp)
1) There is(was) no way of setting SO_REUSEADDR on a socket, which makes
testing servers incredibly tedious (this was a few years ago, it's
since been added)
2) All of (well, at least, enough of) the numeric constants are wrong in the
Alpha Linux port
3) There's no particular regularity to the function names, and they
don't correspond directly to any other API I've used.
4) Whenever anything goes wrong it signals a plain ERROR, which makes
it harder than it need be to create robust clients (what exactly
went wrong? should I give up? retry? ignore? tell the user?)
After seeing (1), I wrote a nasty piece of cut & paste code to
duplicate create-inet-listener adding a :reuse argument. After (2), I
wrote a small C program to dig this stuff and the structure offsets
out of header files. Realising that this was turning into more of a
rewrite than a patch, and would simply be painful to get into the
CMUCL build process, I decided I might as well break compatibility and
fix (3) and (4) while I was at it. My new API was originally
conceptually based on the Perl socket API, but acquired more BSD
features as development went on, because when it comes to needing to
write ugly low-level cruft to set the IP_RECVERR option, I'd rather
deal with one thing at a time instead of having to worry about FFI
glue at the same time.
It's still not _exactly_ the BSD API, but mostly the differences are
- poor choice of types, lack thereof: whoever decided that a "network
byte order long integer" was a sensible data type needs to be slapped
It's a 4-element array of octets, thankyouverymuch, and begone! foul
demons of byte ordering!
- it signals appropriate subclasses of socket-condition where the C
stuff would usually return 0 and set errno
(errno is a rant for another time. Especially on Linux systems)
- it expands the incnsistent WEIRDCNTRCTIONS that C programers love so
much. So, EPROTONOSUPPORT is now PROTOCOL-NOT-SUPPORTED-ERROR and
EOPNOTSUPP became OPERATION-NOT-SUPPORTED-ERROR
Plus sundry other stuff that doesn't come to mind right now, no doubt.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
Daniel Barlow <···@telent.net> writes:
>
> - it expands the incnsistent WEIRDCNTRCTIONS that C programers love so
> much.
That's WRDCNTRCTONS in Posix, I think.
--tim
Will Deakin <········@pindar.com> writes:
> Tim wrote:
> > That's WRDCNTRCTONS in Posix, I think.
> And not Z__WRD_CNTRCTN_S?
No, that's AIX. Or am I thinkihng of HPUX 10?
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
"Jochen Schmidt" <···@dataheaven.de> wrote
> Oh boy - I really begin to think seriously why I should do this...
> The number of people that tell me how useless my effort is and how much
> more important things would be there to *volunteer* is increasing at a
> rate that now begins to significantly reduce my mood to "volunteer" for
> anything more...
It's because people reply to posts when they don't agree. Generally you
don't post just to say "yes, me too". It's not a poll. Also as the thread
subject is about mod_lisp, some people not interested in it don't read these
posts and can't manifest in favor of SSL even if they are interested.
So go on with SSL for LispWorks . It's useful and I will use it (not for
HTTPS for sure ;-) as it works perfectly well for me with
mod_lisp+mod_ssl...) but I have other uses for it. I suggested STunnel as a
temporary solution. It's better to have SSL in LW (watch performance
carefully though, I suspect the LW FFI to be rather slow sometimes)
Marc
I havn't read onward in this thread, but it's time to get a grip.
>> yes. I think it's a complete waste of time. You have other, much
>> more serious, problems if you have an intruder with root access on
>> your machine. Really, you do.
jochen> Oh nice to know that you think creating a integrated SSL
jochen> solution would be a waste of time...
This is not what Tim was saying; at least, I don't think it is.
jochen> Oh boy - I really begin to think seriously why I should do
jochen> this... The number of people that tell me how useless my
jochen> effort is and how much more important things would be there
jochen> to *volunteer* is increasing at a rate that now begins to
jochen> significantly reduce my mood to "volunteer" for anything
jochen> more...
Jochen. It's not as if we're waiting here for you to contribute these
things. Most of us can figure out how to do the same, or find
work-arounds that are equally as good, if need be. The world is not
on your shoulders.
At the same time, no one said or implied that your efforts were
futile. It's true that I would tend not to use your solutions, but
that has little to do with the utility of the contribution, or the
quality of your code. But if you wrote the SSL thing, I'm sure others
would give it a shot.
jochen> saddened,
jochen> Jochen Schmidt
there's no reason to be saddened. Here's the moral of this story:
If you're gonna write free software, write it because *you* need it
-- not as a service to the community.
The best things are written by people who actually need what they
write. If that's the case, then you just spend a tad more time to
make it a bit more generic, and then package it up for others to use.
I wouldn't write it because other people seemed to want it. Then you
start out as a volunteer and up up as some kind of martyr, as this
last post of yours is suggesting.
dave
David Bakhash wrote:
> I havn't read onward in this thread, but it's time to get a grip.
>
> >> yes. I think it's a complete waste of time. You have other, much
> >> more serious, problems if you have an intruder with root access on
> >> your machine. Really, you do.
>
> jochen> Oh nice to know that you think creating a integrated SSL
> jochen> solution would be a waste of time...
>
> This is not what Tim was saying; at least, I don't think it is.
Oh I don't know if you've not read the further posts yet but I think Tim and
I have found our common base... I see no reason to further discuss
misunderstandings!
> jochen> Oh boy - I really begin to think seriously why I should do
> jochen> this... The number of people that tell me how useless my
> jochen> effort is and how much more important things would be there
> jochen> to *volunteer* is increasing at a rate that now begins to
> jochen> significantly reduce my mood to "volunteer" for anything
> jochen> more...
>
> Jochen. It's not as if we're waiting here for you to contribute these
> things. Most of us can figure out how to do the same, or find
> work-arounds that are equally as good, if need be. The world is not
> on your shoulders.
????
What the hell are you talkin about?
I think i have *never* stated that I'm better than any other - if so then
please sorry for that.
> At the same time, no one said or implied that your efforts were
> futile. It's true that I would tend not to use your solutions, but
> that has little to do with the utility of the contribution, or the
> quality of your code. But if you wrote the SSL thing, I'm sure others
> would give it a shot.
I said not that I'm saddened because nobody wants to use my solutions -
they are already used and the numbers are increasing - what I found
saddening is that you feel sometimes like a gratis worker if you're willing
to share your work here. Your talking here doesn't do any better for that...
> jochen> saddened,
> jochen> Jochen Schmidt
>
> there's no reason to be saddened. Here's the moral of this story:
>
> If you're gonna write free software, write it because *you* need it
> -- not as a service to the community.
>
> The best things are written by people who actually need what they
> write. If that's the case, then you just spend a tad more time to
> make it a bit more generic, and then package it up for others to use.
This is exaclty what I'm doing -all things I contribute are written because
*I* need them. But if you want to contribute something you cannot only
throw your working-directory on a website you've to spend some time to
package it (as you write) and make it usable to others and *this* is what I
questioned. I did not question if I should write e. g. the SSL bindings - I
did question if it is worth the effort do make it public and to try to get
it done on other implementations than LispWorks.
> I wouldn't write it because other people seemed to want it. Then you
> start out as a volunteer and up up as some kind of martyr, as this
> last post of yours is suggesting.
???
Is it *so* difficult to understand? I'm no martyr (martyrs are dead... ;-)
) But it _should_ be obvious to you that it is some work to make something
public - and it is _my_ opinion that people that are willing to contribute
something should get some help from the others. I do not ask for much -
answering a simple question (Like Daniel did exemplary) is enough for the
most.
You're right if saying that contributors should offer their work because
the need it by themselves not as a service to the comunity - but it is
insulting being handled then as a gratis worker.
I started this discussion because I think that there is a rather big amount
of opposition against people who wants to contribute something (and not
because _you_ don't use my software...).
As it seems there are other people that think the same - so my intuition
doesn't seem to cheat me.
There's a lot of talking about comunity the last time. I think that we
could do better if we change this attitudes.
we are a bunch of lone rangers - let's start to be a bit more the knights
of the round table...
ciao,
Jochen
On Wed, 20 Jun 2001 11:18:23 +0200, Jochen Schmidt <···@dataheaven.de>
wrote:
>
>I started this discussion because I think that there is a rather big amount
>of opposition against people who wants to contribute something (and not
>because _you_ don't use my software...).
>As it seems there are other people that think the same - so my intuition
>doesn't seem to cheat me.
>There's a lot of talking about comunity the last time. I think that we
>could do better if we change this attitudes.
>
>we are a bunch of lone rangers - let's start to be a bit more the knights
>of the round table...
Was it premonition that made me buy and view a DVD with the movie
"Excalibur" yesterday evening? Anyway, I now have the story fresh in
mind:
Merlin the Necromancer manages to put Excalibur, the Sword of Power, in
the hands of Uther Pendragon.
Excalibur, that means Common Lisp of course.
But Uther makes use of Excalibur for his own good only, not that of his
country, takes unlawful advantage of Igrayne, the wife of one of his
lieges, etc, so he perishes.
Cooperation is the key, not collision. Yes, it fits with Lisp so far.
Enter Arthur, the son of Uther and Igrayne. He, wielding Excalibur,
unites the country, marries Gueneviere and hacks up a round table.
Too little of the sword in this part, too much dancing and too much
sillies. Can it be the AI/Lisp winter?
Sir Lancelot and Gueneviere are accused of you-can-guess-what and
Lancelot has to fight it out with another knight. Not good. I would at
least have gone for Morgana - that witch seemed a lot more yum-yum to
me.
King Arthur himself orders this duel to take place. Not a commendable
leadership: team members must not fight with each other, very bad for
the spirit in the group.
But then he puts the wagon back on the track - the knights are to search
for the holy grail - finding it will cure everything.
And now we see the connection to Lisp clearly - some people have in this
newsgroup referred to LispOs as "the holy grail of all Lispers".
We have the whole setup. Common Lisp is in the picture again. All
jousting was done in the LispOS mailing list(s).
As Merlin said: "That's it! Thats good!".
And as I said in some LispOS threads in this ng, related to LispOs: Do
these and other things because it's fun to do them. I have always found
that having fun is a powerful driving force.
Lars
Jochen Schmidt <···@dataheaven.de> writes:
> The bad thing is not how "super difficult" it is to sniff loopback sockets,
> but the fact that sniffing the sockets is *much* easier than to hack RSA
> RC4 or to inspect the running image of the process.
tcpdump -i lo tcp port 8000
- or -
gdb -p `pidof lisp`
OK, perhaps the former is marginally more convenient, but any
environment in which the latter is possible is fairly obviously not a
secure one either.
-dan
--
http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources
"Jochen Schmidt" <···@dataheaven.de> wrote
> Do you *really* think that this security argumentation is futile and
> unimportant? Do you really think that this dreck doesn't reduce the
> security much?
What others tells you is that if somebody have root access he can do what he
wants. For instance he could replace some shared libraries with trojan
horses. Or he can replace your software with a patched one to dump the
packets you receive, etc. And don't tell me it's impossible, I've done it...
> Cryptography is now a occupation I have for several years - and I'm
> everytime really astonished how most people find the basic rules of
> cryptography and information theory rather unimportant...
I also work with cryptography. When I started my company, it was to make
cryptographic sofware. Now it's only a small part of my activity but I still
do some contract work in that field.
Marc
Marc Battyani wrote:
>
> "Jochen Schmidt" <···@dataheaven.de> wrote
>
>> Do you *really* think that this security argumentation is futile and
>> unimportant? Do you really think that this dreck doesn't reduce the
>> security much?
>
> What others tells you is that if somebody have root access he can do what
> he wants. For instance he could replace some shared libraries with trojan
> horses. Or he can replace your software with a patched one to dump the
> packets you receive, etc. And don't tell me it's impossible, I've done
> it...
I know this -I've done it by myself but exaclty because of this I know too
how to make it more difficult to get fragged in such a "combat zone".
If you introduce your own tools (e. g. don't trust the installed libraries
and tools, then you can reach a usable high grade of security - in this
case the maximum is that of withstanding attacks like memory inspection.
I was asked why I think forwarding proxies are a suboptimal solution for
serious encryption stuff and I think my arguments *are* valid. If I don't
do proxy forwarding I can do a lot of things to make the life of the
attacker difficult - if I use it I can never increase on the security of
sniffing network connections. For this sniffing purposes are alot of tools
available and it is possible to attack an amazingly huge amount of users on
a server with very little effort. It is *so* trivially that the encryption
is practically non-existent.
If you have to attack directly encrypted connections you will have to to
*alot* of more work - particularily if the users use their own tools or are
able to check the executables and libraries if they are modified...
What I get understood wrong is - that I don't say that you should never use
tools like "stunnel" because they are inherently insecure but I simply
*answered* the *question* why _I_ think that this solutions are inferior to
other solutions.
ciao,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
>
> I know this -I've done it by myself but exaclty because of this I know too
> how to make it more difficult to get fragged in such a "combat zone".
> If you introduce your own tools (e. g. don't trust the installed libraries
> and tools, then you can reach a usable high grade of security - in this
> case the maximum is that of withstanding attacks like memory inspection.
I think this is where we differ. I'd regard it as sufficiently easy
to run truss, say, to listen to all your system calls, that I'd regard
a security system that doesn't protect against this as really almost
worthless. But that maybe because I'm not a script kiddie (nor am I
interested in attacking systems, just in case anyone gets the wrong
idea): you may still protect yourself against naive attackers.
--tim
Tim Bradshaw wrote:
> Jochen Schmidt <···@dataheaven.de> writes:
>
>>
>> I know this -I've done it by myself but exaclty because of this I know
>> too how to make it more difficult to get fragged in such a "combat zone".
>> If you introduce your own tools (e. g. don't trust the installed
>> libraries and tools, then you can reach a usable high grade of security -
>> in this case the maximum is that of withstanding attacks like memory
>> inspection.
>
> I think this is where we differ. I'd regard it as sufficiently easy
> to run truss, say, to listen to all your system calls, that I'd regard
> a security system that doesn't protect against this as really almost
> worthless. But that maybe because I'm not a script kiddie (nor am I
> interested in attacking systems, just in case anyone gets the wrong
> idea): you may still protect yourself against naive attackers.
This discussion drives me in an area where it seems that I try to _prove_
that it would be possible to offer absolute security on systems where
others have root access. I do not try anything like that - Inspecting the
memory image or using tools like truss _are_ means that allow a programmer
(or a similarily knowledged guy) to "rather" easily exploit any barrier you
build. I do not question that. What I question is if it is then the right
conclusion to say that connection sniffing is exactly the same risk. Most
admins _I_ know are not good enough programmers to inspect a image or use
truss to inspect a program. Furthermore _one_ difference is that sniffing
makes it trivially easy to investigate many people parallel. This not *so*
easy if you have to inspect a running program. (Yes it is possible - but
not *so* easy). Speaking of "script kiddies": Those know often not much
about the technology to inspect arbitrary running programs for sensual data
- but they _are_ able to use th zillions of ready to use sniffing tools
that are available.
My conclusion was simply that forward proxies add additional opportunities
to attack - and those opportunities are much easier to use for the average
script kiddie than the other opportunities. And I hope we agree that in
*this* discussion the only arguable danger comes from "script kiddies" and
not from professionals (As professional would never have a problem to
exploit a local system with root access)
So the question to answer is not "Is proxy forwarding useless" but "Is
forward-proxy SSL suboptimal to native SSL". And _yes_ it is suboptimal
because you _add_ opportunities to overcome it. But this DOES NOT mean that
I say that it is _not_ possible to exploit native encryption. And I do
_not_ question that it is no big problem to exploit native encryption if
you have local root access.
ciao,
Jochen
Jochen Schmidt <···@dataheaven.de> writes:
>
> My conclusion was simply that forward proxies add additional opportunities
> to attack - and those opportunities are much easier to use for the average
> script kiddie than the other opportunities. And I hope we agree that in
> *this* discussion the only arguable danger comes from "script kiddies" and
> not from professionals (As professional would never have a problem to
> exploit a local system with root access)
Yes I agree.
>
> So the question to answer is not "Is proxy forwarding useless" but "Is
> forward-proxy SSL suboptimal to native SSL". And _yes_ it is suboptimal
> because you _add_ opportunities to overcome it. But this DOES NOT mean that
> I say that it is _not_ possible to exploit native encryption. And I do
> _not_ question that it is no big problem to exploit native encryption if
> you have local root access.
I think it's more complex than that. Proxies can have other wins,
such as centralising key management, load sharing &c &c. But clearly
they have downsides too, I don't want to argue with that.
--tim
Jochen Schmidt <···@dataheaven.de> writes:
> What I get understood wrong is - that I don't say that you should never use
> tools like "stunnel" because they are inherently insecure but I simply
> *answered* the *question* why _I_ think that this solutions are inferior to
> other solutions.
In general I think that the whole use of encrypted sessions is somewhat
overvaluated, since it gets easier and easier to attack the *clients*
instead of the network or the servers. The weakest element in the chain
today is the homogenous setup of most PCs, with the extremely predictable
combination of OS and mail program. And the helplessness of the users
wrt. even the most simple-minded social engineering of trojan designers.
(But don't get me wrong, I'll be standing first in line if you create a
lispworks-aserve with built-in ssl support!)
--
(espen)
On Tue, 19 Jun 2001, Jochen Schmidt wrote:
> Daniel Barlow wrote:
>
> > Jochen Schmidt <···@dataheaven.de> writes:
> >
> >> The problem that is inherent with such port-forwarding solutions is that
> >> you have to ensure that nobody can't sniff between this connection.
> >
> > I would be very very surprised to hear that sniffing from elsewhere on
> > the network would show data on connections bound to loopback sockets.
> > That's a bug in your OS and you should take it up with the OS vendor.
> >
> > Of course, if you're root on the local machine you can sniff the
> > loopback interface if you want to, but at that point you have other
> > avenues open to you anyway, so I don't rate that as an exposure.
>
> The bad thing is not how "super difficult" it is to sniff loopback sockets,
> but the fact that sniffing the sockets is *much* easier than to hack RSA
> RC4 or to inspect the running image of the process.
> It is ridicuous that an admin of a machine is *so* trivially able to read
> your encrypted connection. You _reduce_ the *whole* strength of the
> cryptographic process on the difficulty of a local connection sniff (!).
You could forward via a Unix domain socket. Not as transparent as port
forwarding, but not trivially sniffable either.
Tim
Tim Moore wrote:
> On Tue, 19 Jun 2001, Jochen Schmidt wrote:
>
>> Daniel Barlow wrote:
>>
>> > Jochen Schmidt <···@dataheaven.de> writes:
>> >
>> >> The problem that is inherent with such port-forwarding solutions is
>> >> that you have to ensure that nobody can't sniff between this
>> >> connection.
>> >
>> > I would be very very surprised to hear that sniffing from elsewhere on
>> > the network would show data on connections bound to loopback sockets.
>> > That's a bug in your OS and you should take it up with the OS vendor.
>> >
>> > Of course, if you're root on the local machine you can sniff the
>> > loopback interface if you want to, but at that point you have other
>> > avenues open to you anyway, so I don't rate that as an exposure.
>>
>> The bad thing is not how "super difficult" it is to sniff loopback
>> sockets, but the fact that sniffing the sockets is *much* easier than to
>> hack RSA RC4 or to inspect the running image of the process.
>> It is ridicuous that an admin of a machine is *so* trivially able to read
>> your encrypted connection. You _reduce_ the *whole* strength of the
>> cryptographic process on the difficulty of a local connection sniff (!).
>
> You could forward via a Unix domain socket. Not as transparent as port
> forwarding, but not trivially sniffable either.
It is all the same what you do - doing cryptography through forwarding
always means that you *add* further opportunities to exploit it compared to
the native approach (It *is* essentially the "native Approach" + a pipe to
send data through!). It is IMHO totally obvious that you loose something if
you add complexity without improving security.
How serious this things are depends on the forwarding mechanisms and the
OS. Using such an approach with OSes like Windows 98
is somewhat of a cryptographic suicide. On "more secure" OSes like UNIX you
at least need root access to be able to exploit it. Being root would allow
to exploit the native approach too, but exploiting the native approach is a
good amount more custom and needs a fair amount more wisdom and work than
simple connection sniffing (for which the script kiddies get out of the box
usable tools). Furthermore it is a problem that forwarding-proxy
cryptography is _not_ used only on local computers!!! stunnel runs often on
a gateway server from the LAN to the internet which means that you sensual
data is easily exploitable in the _whole_ LAN. It then depends on the
network topology and a lot of other variables if you're _really_ secure.
So please - don't try to tell me that forward proxy usage is absolutely
equally secure like native cryptography. I did _not_ say that it is *so*
much more insecure that it is not usable anymore - but it *is* a fact that
you loose reliability and this *is* _one_ of the arguments that make it
inferior to the native approach.
Another more practical problem with proxy forwarding is that it is e. g.
increased administration overhead and yet another dependency for your
projects. It is a bit similar like sitting in the kitchen with your
girlfriend and only talking through your mobiles.
IMHO this whole discussion is totally useless - I'm not sure what you try
to prove to me... there is nothing to prove: No question - proxy
forwarding is a usable technology that has it's benefits (apply encryption
to a system without doing any changes to it) but if you're able to change
the system then it makes absolutely no sense to use it. I was asked _why_ I
think that it is inferior to the native approach and I think this is
obvious. Do _you_ have better, more reliable more secure and easier
communication when talking with your mobile than if you talk face to face?
ciao,
Jochen
The http://www.fractalconcept.com/asp/debug test URI did not work as stated
in the mod_lisp protocol page.
I forgot to register it with (interface::add-named-url "/asp/debug"
#'(lambda (request) nil)) giving a missing page error instead of the list of
the request key/value pairs.
Marc