RE: Maximum size of RSA message, was: Re: RSA Encrypt/Decrypt fails
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Reddie, Steven Sent: Sunday, February 25, 2001 4:26 PM To: [EMAIL PROTECTED] Subject: RE: Maximum size of RSA message, was: Re: RSA Encrypt/Decrypt fails The message being encrypted/decrypted MUST be smaller than the modulus of the key. Think about the operation that takes place during encryption: c = m^e mod n where: m is the message to be encrypted, (n,e) is the public key (modulus and exponent) c is the ciphertext (encrypted output) The "mod n" results in the output value, c, being limited to a value in the range 0 to n-1 inclusive. If m is bigger than n then too much data will be thrown away by the modulo operation and it will not be possible to recover the original message. It is not just a matter of clearing the top bit of the message. The message must be a smaller value than the modulus. Steven -- Steven Reddie [EMAIL PROTECTED] Senior Software Engineer Computer Associates Pty Ltd (Australia) -Original Message- From: Guus Sliepen [SMTP:[EMAIL PROTECTED]] Sent: Monday, February 26, 2001 3:55 AM To: [EMAIL PROTECTED] Subject: Maximum size of RSA message, was: Re: RSA Encrypt/Decrypt fails On Wed, Feb 14, 2001 at 02:44:02PM -0800, Joseph Ashwood wrote: Just a guess, but a fairly educated one, try setting flen to 1 byte (or even 1 bit) smaller than the key. What I suspect is happening is you are sometimes trying to encrypt values that are larger than the modulus so you're getting a modular reduction of the value encrypted. Joe I'm having a similar problem. For authentication and key exchange purposes, I generate a random string which is exactly as long as my RSA key is. Then I encrypt it without padding (since the message it is totally random noise and just used once). However, the message is not decrypted properly on the other end when the first bit of the plaintext was set. Why is this? Nowhere in documentation or literature can I find that the first bit should not be set. Is this a bug in OpenSSL? Or is this a known fact? __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
IE vs Netscape Based SSL clients
We have had success using the MS Internet Explorer core (WININET.DLL) to create a WIN32 SSL client. There are a number of exposed API calls in WININET which make this job pretty easy (some of which call other MS DLL's which perform the cypto I'm wondering if the Netscape environment has similar API resources. Has anyone had experiences with Netscape in this regard? TIA Harry __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Looking for an HTTPS client for NT C/C++
John -- Take a look at the WININET.DLL resources on the MS site. This DLL is the core of Internet Explorer and the API set is exposed to developers. The user must have IE installed on their machine (although it needn't be their default browser) for this to work. HTH Harry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of John Townsend Sent: Sunday, November 19, 2000 5:25 PM To: [EMAIL PROTECTED] Subject: Looking for an HTTPS client for NT C/C++ I'm looking for a basic HTTPS client program that will compile and run under NT (preferably with VC++). If it can just GET a page from a named HTTPS server with authentication and echo it to standard output, that would be perfect. I've looked at several examples already (including the ssl/cli.cpp and bio/sconnect.c examples in the OpenSSL distribution and the SSL gadget at Darkspell), but haven't quite found what I'm looking for. The biggest problem is probably that I'm a UNIX programmer, not an NT programmer, and am having various problems getting some of these to port. If someone could send or direct me to a better example, I'd be most grateful. Thanks! -- John E. Townsend Sr. Software Engineer "Machines should work; LEXIS-NEXIS people should think." Dayton OH, USA-- IBM Pollyanna Principle [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: string - file
Albert How about using an HTTPS PUT operation? Best Harry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Albert Serra Sent: Tuesday, June 27, 2000 2:51 AM To: [EMAIL PROTECTED] Subject: string - file Hello again, another question, if I want to transmit a file between the client and the server, do I have to convert the file to a string and then send byte by byte. I am doing the client and the server in C code and I know the SSL_read and SSL_write, but in their declaration the paramater to pass is a string. So is there a function that sends a file using SSL or I have to program it. thanks albert __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Proxy or Firewall
PMFJI... How does one utilize something like a Cisco PIX firewall in an SSL environment? On option the firewall seems to offer is translation of network addresses, so a message that might be routed to vvv.xxx.yyy.zzz (a web-registered address) could rerouted to a private network address by the firewall. But wouldn't that cause some grief at the SSL server when it's fielding a message destined for some private network address, but it's certificate is registered for vvv.xxx.yyy.zzz and an associated domain name? Or is it only the client that is concerned with this match? TIA Harry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Tony Nelson Sent: Monday, May 01, 2000 9:35 AM To: [EMAIL PROTECTED] Subject: Re: Proxy or Firewall On Mon, May 01, 2000 at 08:44:17AM -0600, Mike Nigbor wrote: OK, so how does this differ from a "man-in-the-middle" attack? Since there are two SSL sessions, there must be two session encryption keys and the proxy must be decrypting and re-encrypting everything it sees. If I'm a client, shouldn't I reject such a connection? It doesn't .. it actually is a man-in-the-middle attack.. however, the "attack" is being done by the corporation that writes your paycheck.. and there are very valid reasons for a company to be doing such things.. as a client, (or server) you really have no way of detecting that this is happening.. Basically, you end up w/ this picutre.. --- -- | user | --- session 1 --- | f/w | --- session 2 --- | server | --- -- Hope this helps, Tony Nelson TIS Worldwide, Firewall Admin -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of James Dabbs Sent: Saturday, April 29, 2000 6:41 AM To: [EMAIL PROTECTED] Subject: RE: Proxy or Firewall I believe that many enterprises that do not allow an unbroken SSL connection directly from the client throught the proxy/firewall to the remote server. This is because security policy may allows/disallow certain MIME types in the entity of the HTTP response. For this reason, SSL is "broken" at the proxy, and reestablished with a seperate SSL session between the proxy and the remote server. This is not quite as tansparent to the client, but still fairly so. The proxy is much more complicated. It is my understanding that this scheme is becoming the prevailing security strategy in large corporations, gaining favor over transparent SSL pass through. Am I wrong on this? James Dabbs James Dabbs [EMAIL PROTECTED] Director of Engineering TGA Technologies, Inc. Suite 140, 100 Pinnacle Way Norcross, GA 30071 770-441-2100 ext 126 -Original Message- From: Hansknecht, Deborah A [SMTP:[EMAIL PROTECTED]] Sent: Friday, April 28, 2000 2:57 PM To: '[EMAIL PROTECTED]' Subject:RE: Proxy or Firewall A few comments included within... -Original Message- From: James Dabbs [mailto:[EMAIL PROTECTED]] Sent: April 28, 2000 5:37 AM To: [EMAIL PROTECTED] Subject: RE: Proxy or Firewall ..deleted stuff HTTP over SSL, though, works transparently through almost any proxy. This is because the HTTP client knows that the proxy exists. It sets an SSL session up with the proxy, and tells the proxy to set up a seperate SSL session with the actual server. As long as requests are initiated by the client, everything is OK. Perhaps I missed some context in other messages that makes the above statements correct (and I am probably veering off-topic), but as written this is not true. HTTP works over SSL thru a proxy transparently because the client knows that a proxy exists, (that much is true) but it DOES NOT set up an SSL session. The client sends HTTPS via CONNECT which the proxy just passes on to the end server. Your standard HTTP proxy does not negotiate any SSL session with either client or server. (that is obvious if you remember that you do not need an SSL aware proxy - i.e. Apache with mod-ssl or Apache-SSL - if all you want to do is proxy HTTP or HTTPS requests.) If you are "reverse-proxying" then the proxy DOES negotiate separate SSL sessions with client and server, but that is an entirely different bucket of worms and the client browser doesn't even know that you are using a proxy. __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List
RE: Question about Browser Authenticity
Rene, Nicholas, Ben, Terrell and Goetz -- Thanks to your all for your comments! Most helpful! Harry __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
Question about Browser Authenticity
This may be slightly off-topic, so let me apologize in advance. The SSL protocol requires that the client side (say a browser) use appropriate crypto to read the server's certificate and verify the signature on the transmitted public key (using the public key of a trusted 3rd party such as Verisign). How can the user be certain that their browser (or other SSL3 client) hasn't been compromised -- or that they have a roque version of the client -- which will go through the motions of authenticating the server but really not do a proper job. The result being that the user *thinks* he/she has established a secure connection to the desired party, but in fact are connected to another site. Basically, the issue is how does one ensure (if possible!) that an internet client is using valid methods to verify server certificates? TIA Harry __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: OT: Hardware proxy?
Leland -- I scanned your site and Watchguard's. Both look very interesting and relevant to my needs. We are in the early design phases of a super secure, rather high volume (perhaps 1M hits/8 hr day) environment. The transactions are quite simple. An incoming HTTPS query of about 150 bytes. The response from the secure service is also about 150 bytes long. The HTTPS query will be handled by a farm of NT servers running IIS. We are using ISAPI DLL's (which run under IIS) to handle the HTTPS request. This is the ONLY type of traffic which will traverse the firewall. There will be no need for PC's inside this secure network to browse or access the Internet. The network will be ENTIRELY dedicated to these secure transactions. So what I need Firewall II to do is a). Permit these HTTPS transactions. b). Exclude all other port traffic. c). Provide absolutely no access to the internal NT farm except via the aforementioned HTTPS transactions. d). Perhaps provide protection against denial of service attacks (if that's possible with such a device). e). Be certain that Firewall II can not be hacked or administered by outside parties. Are we are the right track with FireWall II? How do I provide system reduncancy -- with two units running in parallel? TIA Harry (yet other Ph.D.! Mechanical Engineering) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Leland V. Lammert Sent: Thursday, July 22, 1999 9:07 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: OT: Hardware proxy? At 02:47 PM 7/21/99 -0700, Harry Whitehouse wrote: Is there an industrial-strength proxy available commerically which only permits 443 traffic? I know I could get something like MS Proxy Server software and run it on an NT, but the stream of security patches I get from MS regarding NT isn't particularly calming to me -- suppose someone hacks my proxy NT? So is there something more basic -- perhaps a dedicated hardware device -- which would do this job? Harry, It *sounds* like you are describing a 'network appliance firewall'. We sell and have had excellent experience with the Firebox II, from WatchGuard (www.watchguard.com). Moderate cost ($5K), stand-along bright red box - no OS troubles (though it is Linux based), no separate hardware, *really* straightforward management from your admin console, realtime security updates (daily). Lee Leland V. Lammert[EMAIL PROTECTED] Chief Scientist Omnitec Corporation Network/Internet Consultants www.omnitec.net __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
RE: Storing information on the server -- NEWBIE ?
PMFJI -- I'm curious as to what folks have used to separate the SSL server from the "isolated back end". SCSI, RS232, other techniques? Are there commerical solutions available? TIA Harry -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Craig Southeren Sent: Saturday, July 10, 1999 5:20 PM To: [EMAIL PROTECTED] Subject: RE: Storing information on the server -- NEWBIE ? Michael wrote: Credit card information should not be kept on the server. Send it on a one-way only trip to a second machine which is no accessible via the internet. How do you do that, then? (FWIW, I agree with the "one way trip" bit, but it seems to me that "not accessible via the Internet" is a contradiction - "accessible in only a very restricted way" would make more sense). We have taken the approach described by Michael on our network. The SSL server that accepts the information must obviously by connected to the Internet. However, the information is immediately transferred to another machine that, although it is connected to the SSL server, does not have any direct connection to the Internet. Storing the information on the SSL server is a Very Bad Idea (tm), as it makes it available to anyone who can hack into SSL server. Putting it at arms length, whilst not necessarily more secure in an absolute sense, extends the time it will take for someone to crack the connection, which increases the likelihood that you will catch them before they succeed. Regards, Craig Southeren --- Equivalence - home of FireDoor, MibMaster PhonePatch Email: [EMAIL PROTECTED] Web: http://www.equival.com.au Fax: +61 2 4368 1395Voice: +61 2 4368 2118 - __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED] __ OpenSSL Project http://www.openssl.org User Support Mailing List[EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
