|
|
| Author |
Message |
| 25 new of 191 responses total. |
robh
|
|
response 100 of 191:
| 
Feb 3 20:18 UTC 1999 |
You can also find it in the Latin phrase "Sic transit gloria mundis",
which can mean either "Thus passes the glory of the world", or
"Someone named Gloria Mundis threw up on the bus". >8)
|
dpc
|
|
response 101 of 191:
|
Feb 3 20:36 UTC 1999 |
That should be "mundi", the genitive.
|
devnull
|
|
response 102 of 191:
|
Feb 3 21:54 UTC 1999 |
The costs in terms of staff time to run a seprate box as the ssl server
are probably fairly significant. Probably the machine that used to be the
ppp router could deal with a small amount of ssl traffic, if it's still
around and functional. Or some other machine could be used.
If running an ssl server for that were my responsiblitiy, I certainly would not
run it on grex.
|
davel
|
|
response 103 of 191:
|
Feb 4 02:41 UTC 1999 |
Sic transit gloria wednesday ...
|
rcurl
|
|
response 104 of 191:
|
Feb 4 05:21 UTC 1999 |
....wodnesdaeg.
|
pfv
|
|
response 105 of 191:
|
Feb 4 06:57 UTC 1999 |
"wodenstag" (S-pelling I-nC-orrect)
I would imagine the SSL and mail-server combo is a natural, since
neither allows direct acces by the public.
(BTW, (sic) is often used to indicate not only ANOTHERS
misspelling, but also to mark a word you find questionable and,
in the case of "sic?" might imply you aren't sure at all)
|
mdw
|
|
response 106 of 191:
|
Feb 4 11:35 UTC 1999 |
Re #92,#93, "can't we run SSL ourselves", this actually is a
surprisingly complicated issue. SSL itself, is of course "free", but
it's not useful without encryption. That immediately gets you into a
whole can of worms, as various governments have strange rules about
encryption (until very recently, it was illegal to even *own* software
that did encryption in france, & in the US, the federal government
claims it's illegal to export most forms of encryption without a
license, & in practice, without including some mechanism for the gov't
to easily decrypt whatever is sent.
The next hurdle is that SSL almost always uses public key technology,
specifically RSA. There is a company that thinks it owns a "software
patent" on RSA; which means it thinks it has the right to license and
regulate the *use* of their technology. There are several ways which we
might acquire this technology. We might run "apache" + "ssleay". This
is free, but because the rsa implementation isn't licensed by RSA (and
hence they didn't collect any $), they might not like that. We could
purchase and run "stronghold". This is basically an officially licensed
version of "apache + ssleay" using rsaref, and gives us source. Or we
could purchase and run servers from netscape, ibm, microsoft, etc.
These cost $, and come in binary only form.
The next problem is that, in order to use RSA, it's not sufficient to
have the code, it's also necessary to have a certificate - a key pair,
signed by some entity. To do this "right" (and give RSA their slice of
the action), we'd have to purchase a certificate from verisign or some
similar entity. This is more $, and a continuous hassle, because it has
to be renewed, for more $, every year. Another option is to use a
self-signed certificate. ssleay can be used to create such
certificates, but getting client web browsers to use such certificates
is a bit tricky. And, again, ssleay gets into the patent infringement
area.
The final issue has to do with the client side, and the actual amount of
security gained by using ssl. RSA is never used to encrypt a stream of
data, but is instead used to encrypt the initial key exchange; after
this, generally, a stream cipher such as rc4 is used to encrypt the
actual data. Most web browsers come in "export" versions that only
support 40 bit keys, rc4-40. This is very weak, and can be cracked by a
clever computer science student in no time at all. There are also
"us-only" versions of these web browsers that support 128-bit
encryption, but because of US export laws, even most citizens in the US
have the "export" version. Since something like 25% of all grex users
come from india, it would be difficult for us to faciliate giving US
users the secure 128-bit version of the browser. But, if most of our
web transactions were only secured using 40-bit encryption, it's not
clear to me that the amount of security we've gained is much of an
improvement over none at all.
|
janc
|
|
response 107 of 191:
|
Feb 4 18:03 UTC 1999 |
So we write a Java applet, that accepts a credit card number, encrypts
via some reasonably secure method of our own, and sends it to Grex.
Doing that right would be a challenge, but it should be possible to do
something moderately secure.
Couple problems:
- sending a Java applet that implements any kind of secure encryption
to India could be a violation of US law.
- I think part of what the whole Verisign thing does is not only
encrypt your response, but to certify that it is being encrypted
with a key that is the exclusive property of Cyberspace
Communications. That is, it not only ensures a secure channel,
but offers assurances about who is on the other end of that secure
channel. I don't see an easy way to achieve that with the applet.
|
rcurl
|
|
response 108 of 191:
|
Feb 4 18:10 UTC 1999 |
I took "wodnesdaeg" from a dictionary. It's OE, not Ger.
|
aruba
|
|
response 109 of 191:
|
Feb 4 18:22 UTC 1999 |
Re #107: You mean it assures the end user that he's talking with us, or it
assures us we're talking with them?
|
dang
|
|
response 110 of 191:
|
Feb 4 19:59 UTC 1999 |
It assures users they are talking to us. Users can get their own
certificates from Verisign, which can be used (like PGP) to encrypt and
verify email, and (I believe) verify them to us.
|
keesan
|
|
response 111 of 191:
|
Feb 4 22:02 UTC 1999 |
Re 107, can you read Java applets using lynx?
|
janc
|
|
response 112 of 191:
|
Feb 5 00:41 UTC 1999 |
No, but unless you are running lynx on your home computer, instead of Grex,
this would do you no good. The whole point is to encrypt the communication
between the browser and Grex. If the browser is running on Grex, it would
be pointless. If you are dialing into Grex, encryption is only a concern if
you think someone may be tapping your phone lines.
|
devnull
|
|
response 113 of 191:
|
Feb 5 01:13 UTC 1999 |
Or if someone is running a sniffer on the subnet which connects the
terminal server and grex. True, in theory that shouldn't be happening...
Someone ought to ask whether all this work and money is going to cause
grex to come out ahead in the end.
I've noticed that most of the money the Free Software Foundation spends
does not pay programmer's salaries; it happens that there are more people
who work in the distribution office (handling mail order, and other
administrivia) than programmers, and the two programmers spend some
of their time supporting the activities of the distribution office
as well (I get to do whatever sysadmining needs to be done, and the
other programmer writes the accounting software they use). I really
would hate to see a substantial fraction of grex's staff time and
money being spent to allow grex to collect more money.
To bring things back on track, I could point out that using pgp or gpg
probably doesn't cost grex any money, and would support encryption, and
a lot of people (though not necessarily me) seem to think that the costs
of having a credit card account would be made up for by the increased income.
|
rtg
|
|
response 114 of 191:
|
Feb 5 13:47 UTC 1999 |
I don't believe we have to get in the business of distributing
encryption algorithms to anyone. I believe that during the initial RSA
negotiation, the choice of 40 bit or 128-bit encryption is also
negotiated. If the users browser supports 128 bit, the rest of the
exchange will use it. If not, the exchange will proceed using 40 bit
encryption.
|
mdw
|
|
response 115 of 191:
|
Feb 6 06:44 UTC 1999 |
Yes, but, 40-bit encryption is pretty pathetic. Why bother?
|
lilmo
|
|
response 116 of 191:
|
Feb 6 18:38 UTC 1999 |
re #99,#100: Also in the Virginia state motto: "Sic semper tyrannus", "Thus
always to tyrants."
Re #105: I have never seen "sic" used in that sense. When questionsing one's
own spelling, I have seen "(sp?)", but not "(sic?)".
|
rtg
|
|
response 117 of 191:
|
Feb 7 06:29 UTC 1999 |
For the vast majority of people, a simple 1-bit left shift of each
character will mask it enough so the honest among us won't have to see
another's credit card numbers. I transacted lots of CC purchases via
simple e-mail long before the current paranoia about on-line buying hit
the press.
A CC transaction will be a rarity on our web server for quite some time,
untilll ggex merchandise become a lot more popular than they now are, so I
maintain that sniffing our line for CC numbers will be pointless, so the
ne'er-do-wells will be haunting greener pastures.
Let's quit scaring ourselves and get on with it. The original proposal
was only risking about $30 for a year's contract with a CC clearing house.
lets go forward with that, and see how many of our users will use it. We
can make further investments after the initial one has paid off, and if we
get feedback that more people will use it if we had a more secure
server.
AFAIK, netscape doesn't even tell me if i'm using 40-bit or 128-bit
encryption. All I see is the little key appear in the corner, and I
simply trust that its now secure. I have no way of knowing which sites
are using 40 bit, and which are using 128 bit. I tend to believe that
the majority of users out there don't even know that much.
So we go with a minimum contract, and don't bother to set up a server
just yet. We'll get some people who'll take the risk of sending in their
CC# in a simple e-mail, or phone aruba with it(if he's willing to take the
flood of calls, of course). Others may e-mail it, but mask it by
using an unconventional format or puctuation to fool the robot sniffers
looking for the typical 4 groups of four digits. Some may choose to use
the phone, or send part of the number in separate e-mails. Some may
choose not to use a CC until we get a secure server. I still think we'll
get enough business to make having the capability worthwhile
|
devnull
|
|
response 118 of 191:
|
Feb 7 08:47 UTC 1999 |
Re #117: You're forgetting about pgp and gpg...
|
steve
|
|
response 119 of 191:
|
Feb 7 17:48 UTC 1999 |
Right. The simplest way for us to deal with credit cards is pgp
encrypted mail to the treasurer, or a phone call even if that was
ok. We can deal with more complicated things as time goes on.
|
remmers
|
|
response 120 of 191:
|
Feb 7 23:10 UTC 1999 |
Pgp is simpler for us but more complicated for the customer. I suspect
that the amount of CC traffic we'll get depends critically on the
convenience factor. If giving money to Grex via CC isn't significantly
simpler for a lot of people than the methods currently available, it
probably won't be used much. If it *is* significantly more convenient,
i.e. do-able via a web form, it might attract more contributors.
<remmers thinks of amazon.com's "one-click ordering" feature...>
|
jshafer
|
|
response 121 of 191:
|
Feb 10 01:03 UTC 1999 |
I don't know a oout most people, but I would be more
than happy to get my CC# to Mark, possibly via PGP
and email, and have him keep it on file. Then it would
be simple to send him an unencrypted email when it comes
time to renew.
I think Remmers is right, though, that most people would
rather deal with a web form of some sort.
|
steve
|
|
response 122 of 191:
|
Feb 10 02:10 UTC 1999 |
People who know us probably don't care and the email system
would work just fine. But those who like us and want to help
out probably would like a system.
|
remmers
|
|
response 123 of 191:
|
Feb 10 18:14 UTC 1999 |
(Are you implying that people who know us don't like us? ;-)
|
steve
|
|
response 124 of 191:
|
Feb 10 18:17 UTC 1999 |
Heh. No, but it seems to me we have two types of contributors.
Those people who participate in the conferences and such, and get
to know the community. The other type is the kind of person who
sees Grex and really likes it, and wouldn't mind contributing but
(to me anyway) is usually far away, and had there been a convienent
system for them to send a few bucks via credit card, would have
done so.
|