mirrors/openssl
0
0
Fork 0
mirror of https://github.com/openssl/openssl.git synced 2024-11-25 11:03:37 +08:00
Code Issues Packages Projects Releases Wiki Activity

ispell and some other nit-picking

Browse Source
This commit is contained in:
Ulf Möller 2000-09-16 15:39:28 +00:00
parent 439fb8e1e0
commit 1e4e549296
31 changed files with 148 additions and 150 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
doc/crypto/BIO_ctrl.pod
View File

@ -58,14 +58,14 @@ be closed when the BIO is freed.
BIO_get_close() returns the BIOs close flag.
BIO_pending(), BIO_ctrl_pending(), BIO_wpending() and BIO_ctrl_wpending()
return the number of pending characterers in the BIOs read and write buffers.
return the number of pending characters in the BIOs read and write buffers.
Not all BIOs support these calls. BIO_ctrl_pending() and BIO_ctrl_wpending()
return a size_t type and are functions, BIO_pending() and BIO_wpending() are
macros which call BIO_ctrl().
=head1 RETURN VALUES
BIO_reset() returns 1 fo success and 0 for failure.
BIO_reset() returns 1 for success and 0 for failure.
BIO_flush() returns 1 for success and 0 or -1 for failure.
@ -97,7 +97,7 @@ This often means there is no need to locate the required BIO for
a particular operation, it can be called on a chain and it will
be automatically passed to the relevant BIO.
Source/sink BIOs will return an error if the do not recognise the
Source/sink BIOs will return an error if the do not recognize the
BIO_ctrl() operation.
=head1 SEE ALSO

2
doc/crypto/BIO_f_cipher.pod
View File

@ -38,7 +38,7 @@ is a BIO_ctrl() macro which can be called to determine whether the
decryption operation was successful.
BIO_get_cipher_ctx() is a BIO_ctrl() macro which retrieves the internal
BIO cipher context. The retrieved context can be used in conjustion
BIO cipher context. The retrieved context can be used in conjunction
with the standard cipher routines to set it up. This is useful when
BIO_set_cipher() is not flexible enough for the applications needs.

4
doc/crypto/BIO_f_md.pod
View File

@ -31,7 +31,7 @@ not supported.
BIO_reset() reinitializes a digest BIO.
BIO_set_md() sets the message digest of BIO B<b> to B<md>: this
must be called to initialise a digest BIO before any data is
must be called to initialize a digest BIO before any data is
passed through it. It is a BIO_ctrl() macro.
BIO_get_md() places the a pointer to the digest BIOs digest method
@ -127,7 +127,7 @@ outputs them. This could be used with the examples above.
=head1 BUGS
The lack of support for BIO_puts() and the non standard behaviour of
The lack of support for BIO_puts() and the non standard behavior of
BIO_gets() could be regarded as anomalous. It could be argued that BIO_gets()
and BIO_puts() should be passed to the next BIO in the chain and digest
the data passed through and that digests should be retrieved using a

6
doc/crypto/BIO_f_ssl.pod
View File

@ -33,7 +33,7 @@ BIO_ssl_shutdown - SSL BIO
=head1 DESCRIPTION
BIO_f_ssl() returns the SSL BIO method. This is a filter BIO which
is a wrapper round the OpenSSL SSL routines adding a BIO "flavour" to
is a wrapper round the OpenSSL SSL routines adding a BIO "flavor" to
SSL I/O.
I/O performed on an SSL BIO communicates using the SSL protocol with
@ -65,7 +65,7 @@ the SSL session is automatically renegotiated. B<num> must be at
least 512 bytes.
BIO_set_ssl_renegotiate_timeout() sets the renegotiate timeout to
B<seconds>. When the renegotiate timeout elapses the sesssion is
B<seconds>. When the renegotiate timeout elapses the session is
automatically renegotiated.
BIO_get_num_renegotiates() returns the total number of session
@ -100,7 +100,7 @@ renegotiation takes place during a BIO_read() operation, one
case where this happens is when SGC or step up occurs.
In OpenSSL 0.9.6 and later the SSL flag SSL_AUTO_RETRY can be
set to disable this behaviour. That is when this flag is set
set to disable this behavior. That is when this flag is set
an SSL BIO using a blocking transport will never request a
retry.

2
doc/crypto/BIO_new.pod
View File

@ -40,7 +40,7 @@ BIO_free_all() and BIO_vfree() do not return values.
=head1 NOTES
Some BIOs (such as memory BIOs) can be used immediately after calling
BIO_new(). Others (such as file BIOs) need some additional initialisation,
BIO_new(). Others (such as file BIOs) need some additional initialization,
and frequently a utility function exists to create and initialize such BIOs.
If BIO_free() is called on a BIO chain it will only free one BIO resulting

6
doc/crypto/BIO_new_bio_pair.pod
View File

@ -25,8 +25,8 @@ BIO_new_bio_pair() does not check whether B<bio1> or B<bio2> do point to
some other BIO, the values are overwritten, BIO_free() is not called.
The two BIOs, even though forming a BIO pair and must be BIO_free()'ed
seperately. This can be of importance, as some SSL-functions like SSL_set_bio()
or SSL_free() call BIO_free() implicitely, so that the peer-BIO is left
separately. This can be of importance, as some SSL-functions like SSL_set_bio()
or SSL_free() call BIO_free() implicitly, so that the peer-BIO is left
untouched and must also be BIO_free()'ed.
=head1 EXAMPLE
@ -53,7 +53,7 @@ without having to go through the SSL-interface.
socket |
...
SSL_free(ssl); /* implicitely frees internal_bio */
SSL_free(ssl); /* implicitly frees internal_bio */
BIO_free(network_bio);
...

4
doc/crypto/BIO_read.pod
View File

@ -43,8 +43,8 @@ it may merely be an indication that no data is currently available and that
the application should retry the operation later.
One technique sometimes used with blocking sockets is to use a system call
(such as select(), poll() or eqivalent) to determine when data is available
and then call read() to read the data. The eqivalent with BIOs (that is call
(such as select(), poll() or equivalent) to determine when data is available
and then call read() to read the data. The equivalent with BIOs (that is call
select() on the underlying I/O structure and then call BIO_read() to
read the data) should B<not> be used because a single call to BIO_read()
can cause several reads (and writes in the case of SSL BIOs) on the underlying

2
doc/crypto/BIO_s_accept.pod
View File

@ -100,7 +100,7 @@ BIO is not at then end of a chain it passes I/O calls to the next
BIO in the chain.
When a connection is established a new socket BIO is created for
the conection and appended to the chain. That is the chain is now
the connection and appended to the chain. That is the chain is now
accept->socket. This effectively means that attempting I/O on
an initial accept socket will await an incoming connection then
perform I/O on it.

8
doc/crypto/BIO_s_bio.pod
View File

@ -61,7 +61,7 @@ BIO_destroy_pair() destroys the association between two connected BIOs. Freeing
up any half of the pair will automatically destroy the association.
BIO_set_write_buf_size() sets the write buffer size of BIO B<b> to B<size>.
If the size is not initialised a default value is used. This is currently
If the size is not initialized a default value is used. This is currently
17K, sufficient for a maximum size TLS record.
BIO_get_write_buf_size() returns the size of the write buffer.
@ -71,7 +71,7 @@ BIO_set_write_buf_size() to create a connected pair of BIOs B<bio1>, B<bio2>
with write buffer sizes B<writebuf1> and B<writebuf2>. If either size is
zero then the default size is used.
BIO_get_write_guarantee() and BIO_ctrl_get_write_guarentee() return the maximum
BIO_get_write_guarantee() and BIO_ctrl_get_write_guarantee() return the maximum
length of data that can be currently written to the BIO. Writes larger than this
value will return a value from BIO_write() less than the amount requested or if the
buffer is full request a retry. BIO_ctrl_get_write_guarantee() is a function
@ -89,7 +89,7 @@ BIO_get_read_request() to zero.
=head1 NOTES
Both halves of a BIO pair should be freed. That is even if one half is implicity
Both halves of a BIO pair should be freed. That is even if one half is implicit
freed due to a BIO_free_all() or SSL_free() call the other half needs to be freed.
When used in bidirectional applications (such as TLS/SSL) care should be taken to
@ -103,7 +103,7 @@ BIO_write() and a response read with BIO_read(), this can occur during an
TLS/SSL handshake for example. BIO_write() will succeed and place data in the write
buffer. BIO_read() will initially fail and BIO_should_read() will be true. If
the application then waits for data to be available on the underlying transport
before flusing the write buffer it will never succeed because the request was
before flushing the write buffer it will never succeed because the request was
never sent!
=head1 EXAMPLE

8
doc/crypto/BIO_s_connect.pod
View File

@ -66,13 +66,13 @@ fails a standard table of port names will be used. Currently the
list is http, telnet, socks, https, ssl, ftp, gopher and wais.
BIO_set_conn_ip() sets the IP address to B<ip> using binary form,
that is four bytes specifying the IP address in big endian form.
that is four bytes specifying the IP address in big-endian form.
BIO_set_conn_int_port() sets the port using B<port>. B<port> should
be of type (int *).
BIO_get_conn_hostname() returns the hostname of the connect BIO or
NULL if the BIO is initialised but no hostname is set.
NULL if the BIO is initialized but no hostname is set.
This return value is an internal pointer which should not be modified.
BIO_get_conn_port() returns the port as a string.
@ -120,7 +120,7 @@ It addition to BIO_should_read() and BIO_should_write() it is also
possible for BIO_should_io_special() to be true during the initial
connection process with the reason BIO_RR_CONNECT. If this is returned
then this is an indication that a connection attempt would block,
the application should then take appropiate action to wait until
the application should then take appropriate action to wait until
the underlying socket has connected and retry the call.
=head1 RETURN VALUES
@ -128,7 +128,7 @@ the underlying socket has connected and retry the call.
BIO_s_connect() returns the connect BIO method.
BIO_get_fd() returns the socket or -1 if the BIO has not
been initialised.
been initialized.
BIO_set_conn_hostname(), BIO_set_conn_port(), BIO_set_conn_ip() and
BIO_set_conn_int_port() always return 1.

8
doc/crypto/BIO_s_fd.pod
View File

@ -36,11 +36,11 @@ BIO_get_fd() places the file descriptor in B<c> if it is not NULL, it also
returns the file descriptor. If B<c> is not NULL it should be of type
(int *).
BIO_new_fd() returns a file desciptor BIO using B<fd> and B<close_flag>.
BIO_new_fd() returns a file descriptor BIO using B<fd> and B<close_flag>.
=head1 NOTES
The behaviour of BIO_read() and BIO_write() depends on the behaviour of the
The behavior of BIO_read() and BIO_write() depends on the behavior of the
platforms read() and write() calls on the descriptor. If the underlying
file descriptor is in a non blocking mode then the BIO will behave in the
manner described in the L<BIO_read(3)|BIO_read(3)> and L<BIO_should_retry(3)|BIO_should_retry(3)>
@ -56,12 +56,12 @@ BIO_s_fd() returns the file descriptor BIO method.
BIO_reset() returns zero for success and -1 if an error occurred.
BIO_seek() and BIO_tell() return the current file position or -1
is an error occurred. These values reflect the underlying lseek()
behaviour.
behavior.
BIO_set_fd() always returns 1.
BIO_get_fd() returns the file descriptor or -1 if the BIO has not
been initialised.
been initialized.
BIO_new_fd() returns the newly allocated BIO or NULL is an error
occurred.

2
doc/crypto/BIO_s_file.pod
View File

@ -66,7 +66,7 @@ When wrapping stdout, stdin or stderr the underlying stream should not
normally be closed so the BIO_NOCLOSE flag should be set.
Because the file BIO calls the underlying stdio functions any quirks
in stdio behaviour will be mirrored by the corresponding BIO.
in stdio behavior will be mirrored by the corresponding BIO.
=head1 EXAMPLES

6
doc/crypto/BIO_s_mem.pod
View File

@ -43,7 +43,7 @@ BIO_eof() is true if no data is in the BIO.
BIO_ctrl_pending() returns the number of bytes currently stored.
BIO_set_mem_eof_return() sets the behaviour of memory BIO B<b> when it is
BIO_set_mem_eof_return() sets the behavior of memory BIO B<b> when it is
empty. If the B<v> is zero then an empty memory BIO will return EOF (that is
it will return zero and BIO_should_retry(b) will be false. If B<v> is non
zero then it will return B<v> when it is empty and it will set the read retry
@ -87,9 +87,7 @@ There should be a way to "rewind" a read write BIO without destroying
its contents.
The copying operation should not occur after every small read of a large BIO
to improve efficieny.
There shoy
to improve efficiency.
=head1 EXAMPLE

2
doc/crypto/BIO_s_socket.pod
View File

@ -51,7 +51,7 @@ BIO_s_socket() returns the socket BIO method.
BIO_set_fd() always returns 1.
BIO_get_fd() returns the socket or -1 if the BIO has not been
initialised.
initialized.
BIO_new_socket() returns the newly allocated BIO or NULL is an error
occurred.

2
doc/crypto/BIO_should_retry.pod
View File

@ -97,7 +97,7 @@ the performance may be poor if SSL BIOs are present because long delays
can occur during the initial handshake process.
It is possible for a BIO to block indefinitely if the underlying I/O
structure cannot process or return any data. This depends on the behaviour of
structure cannot process or return any data. This depends on the behavior of
the platforms I/O functions. This is often not desirable: one solution
is to use non blocking I/O and use a timeout on the select() (or
equivalent) call.

4
doc/ssl/SSL_SESSION_free.pod
View File

@ -2,7 +2,7 @@
=head1 NAME
SSL_SESSION_free - Free up an allocated SSL_SESSION structure
SSL_SESSION_free - free an allocated SSL_SESSION structure
=head1 SYNOPSIS
@ -13,7 +13,7 @@ SSL_SESSION_free - Free up an allocated SSL_SESSION structure
=head1 DESCRIPTION
SSL_SESSION_free() decrements the reference count of B<session> and removes
the SSL_SESSION structure pointed to by B<session> and frees up the allocated
the B<SSL_SESSION> structure pointed to by B<session> and frees up the allocated
memory, if the the reference count has reached 0.
=head1 RETURN VALUES

32
doc/ssl/SSL_accept.pod
View File

@ -2,7 +2,7 @@
=head1 NAME
SSL_accept - Wait for a TLS client to initiate a TLS handshake
SSL_accept - wait for a TLS/SSL client to initiate a TLS/SSL handshake
=head1 SYNOPSIS
@ -12,22 +12,22 @@ SSL_accept - Wait for a TLS client to initiate a TLS handshake
=head1 DESCRIPTION
SSL_accept() waits for a TLS client to initiate the TLS handshake.
SSL_accept() waits for a TLS/SSL client to initiate the TLS/SSL handshake.
The communication channel must already have been set and assigned to the
B<ssl> by setting an underlying B<BIO>. The behaviour of SSL_accept() depends
B<ssl> by setting an underlying B<BIO>. The behavior of SSL_accept() depends
on the underlying BIO.
If the underlying BIO is B<blocking>, SSL_accept() will only return, once the
handshake has been finished or an error occured, except for SGC (Server
Gated Cryptography). For SGC SSL_accept() may return with -1 but
SSL_get_error() will yield SSL_ERROR_WANT_READ/WRITE and SSL_accept()
If the underlying BIO is B<blocking>, SSL_accept() will only return once the
handshake has been finished or an error occurred, except for SGC (Server
Gated Cryptography). For SGC, SSL_accept() may return with -1, but
SSL_get_error() will yield B<SSL_ERROR_WANT_READ/WRITE> and SSL_accept()
should be called again.
If the underlying BIO is B<non-blocking>, SSL_accept() will also return,
If the underlying BIO is B<non-blocking>, SSL_accept() will also return
when the underlying BIO could not satisfy the needs of SSL_accept()
to continue the handshake. In this case a call to SSL_get_error() with the
return value of SSL_accept() will yield SSL_ERROR_WANT_READ or
SSL_ERROR_WANT_WRITE. The calling process then must repeat the call after
return value of SSL_accept() will yield B<SSL_ERROR_WANT_READ> or
B<SSL_ERROR_WANT_WRITE>. The calling process then must repeat the call after
taking appropriate action to satisfy the needs of SSL_accept().
The action depends on the underlying BIO. When using a non-blocking socket,
nothing is to be done, but select() can be used to check for the required
@ -42,20 +42,20 @@ The following return values can occur:
=item 1
The TLS handshake was successfully completed, a TLS connection has been
The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
established.
=item 0
The TLS handshake was not successfull but was shut down controlled and
by the specifications of the TLS protocol. Call SSL_get_error() with the
The TLS/SSL handshake was not successful but was shut down controlled and
by the specifications of the TLS/SSL protocol. Call SSL_get_error() with the
return value B<ret> to find out the reason.
=item -1
The TLS handshake was not successfull, because a fatal error occured either
at the protocol level or a connection failure occured. The shutdown was
not clean. It can also occure of action is need to continue the operation
The TLS/SSL handshake was not successful because a fatal error occurred either
at the protocol level or a connection failure occurred. The shutdown was
not clean. It can also occur of action is need to continue the operation
for non-blocking BIOs. Call SSL_get_error() with the return value B<ret>
to find out the reason.

10
doc/ssl/SSL_clear.pod
View File

@ -2,7 +2,7 @@
=head1 NAME
SSL_clear - Reset SSL to allow another connection
SSL_clear - reset SSL object to allow another connection
=head1 SYNOPSIS
@ -12,9 +12,9 @@ SSL_clear - Reset SSL to allow another connection
=head1 DESCRIPTION
Reset the B<ssl> to allow another connection. All settings (method, ciphers,
BIOs) are kept. A completely negotiated SSL_SESSION is not freed but left
untouched for the underlying SSL_CTX.
Reset B<ssl> to allow another connection. All settings (method, ciphers,
BIOs) are kept. A completely negotiated B<SSL_SESSION> is not freed but left
untouched for the underlying B<SSL_CTX>.
=head1 RETURN VALUES
@ -29,7 +29,7 @@ find out the reason.
=item 1
The SSL_clear() operation was successfull.
The SSL_clear() operation was successful.
=back

26
doc/ssl/SSL_connect.pod
View File

@ -2,7 +2,7 @@
=head1 NAME
SSL_connect - Initiate the TLS handshake with an TLS server
SSL_connect - initiate the TLS/SSL handshake with an TLS/SSL server
=head1 SYNOPSIS
@ -14,17 +14,17 @@ SSL_connect - Initiate the TLS handshake with an TLS server
SSL_connect() initiates the TLS handshake with a server. The communication
channel must already have been set and assigned to the B<ssl> by setting an
underlying B<BIO>. The behaviour of SSL_connect() depends on the underlying
underlying B<BIO>. The behavior of SSL_connect() depends on the underlying
BIO.
If the underlying BIO is B<blocking>, SSL_connect() will only return, once the
handshake has been finished or an error occured.
If the underlying BIO is B<blocking>, SSL_connect() will only return once the
handshake has been finished or an error occurred.
If the underlying BIO is B<non-blocking>, SSL_connect() will also return,
If the underlying BIO is B<non-blocking>, SSL_connect() will also return
when the underlying BIO could not satisfy the needs of SSL_connect()
to continue the handshake. In this case a call to SSL_get_error() with the
return value of SSL_connect() will yield SSL_ERROR_WANT_READ or
SSL_ERROR_WANT_WRITE. The calling process then must repeat the call after
return value of SSL_connect() will yield B<SSL_ERROR_WANT_READ> or
B<SSL_ERROR_WANT_WRITE>. The calling process then must repeat the call after
taking appropriate action to satisfy the needs of SSL_connect().
The action depends on the underlying BIO. When using a non-blocking socket,
nothing is to be done, but select() can be used to check for the required
@ -39,20 +39,20 @@ The following return values can occur:
=item 1
The TLS handshake was successfully completed, a TLS connection has been
The TLS/SSL handshake was successfully completed, a TLS/SSL connection has been
established.
=item 0
The TLS handshake was not successfull but was shut down controlled and
by the specifications of the TLS protocol. Call SSL_get_error() with the
The TLS/SSL handshake was not successful but was shut down controlled and
by the specifications of the TLS/SSL protocol. Call SSL_get_error() with the
return value B<ret> to find out the reason.
=item -1
The TLS handshake was not successfull, because a fatal error occured either
at the protocol level or a connection failure occured. The shutdown was
not clean. It can also occure of action is need to continue the operation
The TLS/SSL handshake was not successful, because a fatal error occurred either
at the protocol level or a connection failure occurred. The shutdown was
not clean. It can also occur of action is need to continue the operation
for non-blocking BIOs. Call SSL_get_error() with the return value B<ret>
to find out the reason.

8
doc/ssl/SSL_free.pod
View File

@ -2,7 +2,7 @@
=head1 NAME
SSL_free - Free up an allocated SSL structure
SSL_free - free an allocated SSL structure
=head1 SYNOPSIS
@ -12,13 +12,13 @@ SSL_free - Free up an allocated SSL structure
=head1 DESCRIPTION
SSL_free() decrements the reference count of B<ssl> and removes the SSL
structure pointed to by B<ssl> and frees up the allocated memory, if the
SSL_free() decrements the reference count of B<ssl>, and removes the SSL
structure pointed to by B<ssl> and frees up the allocated memory if the
the reference count has reached 0.
It also calls the free()ing procedures for indirectly affected items, if
applicable: the buffering BIO, the read and write BIOs,
cipher lists especially created for this B<ssl>, the SSL_SESSION.
cipher lists specially created for this B<ssl>, the B<SSL_SESSION>.
Do not explicitly free these indirectly freed up items before or after
calling SSL_free(), as trying to free things twice may lead to program
failure.

16
doc/ssl/SSL_get_error.pod
View File

@ -2,7 +2,7 @@
=head1 NAME
SSL_get_error - obtain result code for SSL I/O operation
SSL_get_error - obtain result code for TLS/SSL I/O operation
=head1 SYNOPSIS
@ -15,14 +15,14 @@ SSL_get_error - obtain result code for SSL I/O operation
SSL_get_error() returns a result code (suitable for the C "switch"
statement) for a preceding call to SSL_connect(), SSL_accept(),
SSL_read(), or SSL_write() on B<ssl>. The value returned by that
SSL I/O function must be passed to SSL_get_error() in parameter
TLS/SSL I/O function must be passed to SSL_get_error() in parameter
B<ret>.
In addition to B<ssl> and B<ret>, SSL_get_error() inspects the
current thread's OpenSSL error queue. Thus, SSL_get_error() must be
used in the same thread that performed the SSL I/O operation, and no
used in the same thread that performed the TLS/SSL I/O operation, and no
other OpenSSL function calls should appear in between. The current
thread's error queue must be empty before the SSL I/O operation is
thread's error queue must be empty before the TLS/SSL I/O operation is
attempted, or SSL_get_error() will not work reliably.
=head1 RETURN VALUES
@ -33,12 +33,12 @@ The following return values can currently occur:
=item SSL_ERROR_NONE
The SSL I/O operation completed. This result code is returned
The TLS/SSL I/O operation completed. This result code is returned
if and only if B<ret E<gt> 0>.
=item SSL_ERROR_ZERO_RETURN
The SSL connection has been closed. If the protocol version is SSL 3.0
The TLS/SSL connection has been closed. If the protocol version is SSL 3.0
or TLS 1.0, this result code is returned only if a closure
alert has occurred in the protocol, i.e. if the connection has been
closed cleanly. Note that in this case B<SSL_ERROR_ZERO_RETURN>
@ -47,13 +47,13 @@ has been closed.
=item SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE
The operation did not complete; the same SSL I/O function should be
The operation did not complete; the same TLS/SSL I/O function should be
called again later. There will be protocol progress if, by then, the
underlying B<BIO> has data available for reading (if the result code is
B<SSL_ERROR_WANT_READ>) or allows writing data (B<SSL_ERROR_WANT_WRITE>).
For socket B<BIO>s (e.g. when SSL_set_fd() was used) this means that
select() or poll() on the underlying socket can be used to find out
when the SSL I/O function should be retried.
when the TLS/SSL I/O function should be retried.
Caveat: Any SSL I/O function can lead to either of
B<SSL_ERROR_WANT_READ> and B<SSL_ERROR_WANT_WRITE>, i.e. SSL_read()

2
doc/ssl/SSL_get_fd.pod
View File

@ -2,7 +2,7 @@
=head1 NAME
SSL_get_fd - Get file descriptor linked to an SSL
SSL_get_fd - get file descriptor linked to an SSL object
=head1 SYNOPSIS

4
doc/ssl/SSL_get_rbio.pod
View File

@ -2,7 +2,7 @@
=head1 NAME
SSL_get_rbio - Get BIO linked to an SSL
SSL_get_rbio - get BIO linked to an SSL object
=head1 SYNOPSIS
@ -25,7 +25,7 @@ The following return values can occur:
=item NULL
No BIO was connected to the SSL
No BIO was connected to the SSL object
=item Any other pointer

8
doc/ssl/SSL_get_session.pod
View File

@ -2,7 +2,7 @@
=head1 NAME
SSL_get_session - Retrieve SSL session data
SSL_get_session - retrieve TLS/SSL session data
=head1 SYNOPSIS
@ -14,15 +14,15 @@ SSL_get_session - Retrieve SSL session data
=head1 DESCRIPTION
SSL_get_session() returns a pointer to the SSL session actually used in
B<ssl>. The reference count of the SSL session is not incremented, so
SSL_get_session() returns a pointer to the B<SSL_SESSION> actually used in
B<ssl>. The reference count of the B<SSL_SESSION> is not incremented, so
that the pointer can become invalid when the B<ssl> is freed and
SSL_SESSION_free() is implicitly called.
SSL_get0_session() is the same as SSL_get_session().
SSL_get1_session() is the same as SSL_get_session(), but the reference
count of the SSL session is incremented by one.
count of the B<SSL_SESSION> is incremented by one.
=head1 RETURN VALUES

16
doc/ssl/SSL_new.pod
View File

@ -2,7 +2,7 @@
=head1 NAME
SSL_new - Create a new SSL structure for a connection
SSL_new - create a new SSL structure for a connection
=head1 SYNOPSIS
@ -12,10 +12,10 @@ SSL_new - Create a new SSL structure for a connection
=head1 DESCRIPTION
SSL_new() creates a new B<SSL> structure which is needed to hold the data
for a SSL connection. The new SSL inherits the settings of the underlying
context B<ctx>: connection method (SSLv2/v3/TLSv1), options, verification
settings, timeout settings.
SSL_new() creates a new B<SSL> structure which is needed to hold the
data for a TLS/SSL connection. The new structure inherits the settings
of the underlying context B<ctx>: connection method (SSLv2/v3/TLSv1),
options, verification settings, timeout settings.
=head1 RETURN VALUES
@ -25,10 +25,10 @@ The following return values can occur:
=item NULL
The creation of a new SSL failed. Check the error stack to find out the
reason.
The creation of a new SSL structure failed. Check the error stack to
find out the reason.
=item Pointer to an SSL
=item Pointer to an SSL structure
The return value points to an allocated SSL structure.

26
doc/ssl/SSL_read.pod
View File

@ -2,7 +2,7 @@
=head1 NAME
SSL_read - Read bytes from a TLS connection.
SSL_read - read bytes from a TLS/SSL connection.
=head1 SYNOPSIS
@ -13,20 +13,20 @@ SSL_read - Read bytes from a TLS connection.
=head1 DESCRIPTION
SSL_read() tries to read B<num> bytes from the specified B<ssl> into the
buffer B<buf>. If necessary, SSL_read() will negotiate a TLS session, if
not already explicitely performed by SSL_connect() or SSL_accept(). If the
buffer B<buf>. If necessary, SSL_read() will negotiate a TLS/SSL session, if
not already explicitly performed by SSL_connect() or SSL_accept(). If the
peer requests a re-negotiation, it will be performed transparently during
the SSL_read() operation. The behaviour of SSL_read() depends on the
the SSL_read() operation. The behavior of SSL_read() depends on the
underlying BIO.
If the underlying BIO is B<blocking>, SSL_read() will only return, once the
read operation has been finished or an error occured.
read operation has been finished or an error occurred.
If the underlying BIO is B<non-blocking>, SSL_read() will also return,
If the underlying BIO is B<non-blocking>, SSL_read() will also return
when the underlying BIO could not satisfy the needs of SSL_read()
to continue the operation. In this case a call to SSL_get_error() with the
return value of SSL_read() will yield SSL_ERROR_WANT_READ or
SSL_ERROR_WANT_WRITE. As at any time a re-negotiation is possible, a
return value of SSL_read() will yield B<SSL_ERROR_WANT_READ> or
B<SSL_ERROR_WANT_WRITE>. As at any time a re-negotiation is possible, a
call to SSL_read() can also cause write operations! The calling process
then must repeat the call after taking appropriate action to satisfy the
needs of SSL_read(). The action depends on the underlying BIO. When using a
@ -42,18 +42,18 @@ The following return values can occur:
=item E<gt>0
The read operation was successfull, the return value is the number of
bytes actually read from the TLS connection.
The read operation was successful; the return value is the number of
bytes actually read from the TLS/SSL connection.
=item 0
The read operation was not successfull, probably because no data was
The read operation was not successful, probably because no data was
available. Call SSL_get_error() with the return value B<ret> to find out,
whether an error occured.
whether an error occurred.
=item -1
The read operation was not successfull, because either an error occured
The read operation was not successful, because either an error occurred
or action must be taken by the calling process. Call SSL_get_error() with the
return value B<ret> to find out the reason.

10
doc/ssl/SSL_set_bio.pod
View File

@ -2,7 +2,7 @@
=head1 NAME
SSL_set_bio - Connect the SSL with a BIO
SSL_set_bio - connect the SSL object with a BIO
=head1 SYNOPSIS
@ -13,10 +13,10 @@ SSL_set_bio - Connect the SSL with a BIO
=head1 DESCRIPTION
SSL_set_bio() connects the BIOs B<rbio> and B<wbio> for the read and write
operations of the TLS (encrypted) side of B<ssl>.
operations of the TLS/SSL (encrypted) side of B<ssl>.
The SSL engine inherits the behaviour of B<rbio> and B<wbio>, respectively.
If a BIO is non-blocking, the B<ssl> will also have non-blocking behaviour.
The SSL engine inherits the behavior of B<rbio> and B<wbio>, respectively.
If a BIO is non-blocking, the B<ssl> will also have non-blocking behavior.
If there was already a BIO connected to B<ssl>, BIO_free() will be called
(for both the reading and writing side, if different).
@ -29,6 +29,6 @@ SSL_set_bio() cannot fail.
L<SSL_get_rbio(3)|SSL_get_rbio(3)>,
L<SSL_connect(3)|SSL_connect(3)>, L<SSL_accept(3)|SSL_accept(3)>,
L<SSL_shutdown(3)|SSL_shutdown(3)>, L<ssl(3)|ssl(3)> , L<bio(3)|bio(3)>
L<SSL_shutdown(3)|SSL_shutdown(3)>, L<ssl(3)|ssl(3)>, L<bio(3)|bio(3)>
=cut

12
doc/ssl/SSL_set_fd.pod
View File

@ -2,7 +2,7 @@
=head1 NAME
SSL_set_fd - Connect the SSL with a file descriptor
SSL_set_fd - connect the SSL object with a file descriptor
=head1 SYNOPSIS
@ -15,19 +15,19 @@ SSL_set_fd - Connect the SSL with a file descriptor
=head1 DESCRIPTION
SSL_set_fd() sets the file descriptor B<fd> as the input/output facility
for the TLS (encrypted) side of SSL engine. B<fd> will typically be the
for the TLS/SSL (encrypted) side of B<ssl>. B<fd> will typically be the
socket file descriptor of a network connection.
When performing the operation, a B<socket BIO> is automatically created to
interface between the B<ssl> and B<fd>. The BIO and hence the SSL engine
inherit the behaviour of B<fd>. If B<fd> is non-blocking, the B<ssl> will
also have non-blocking behaviour.
inherit the behavior of B<fd>. If B<fd> is non-blocking, the B<ssl> will
also have non-blocking behavior.
If there was already a BIO connected to B<ssl>, BIO_free() will be called
(for both the reading and writing side, if different).
SSL_set_rfd() and SSL_set_wfd() perform the respective action but only
for the read channel or the write channel, which can be set independantly.
SSL_set_rfd() and SSL_set_wfd() perform the respective action, but only
for the read channel or the write channel, which can be set independently.
=head1 RETURN VALUES

10
doc/ssl/SSL_set_session.pod
View File

@ -2,7 +2,7 @@
=head1 NAME
SSL_set_session - Set an SSL session to be used during SSL connect
SSL_set_session - set a TLS/SSL session to be used during TLS/SSL connect
=head1 SYNOPSIS
@ -12,15 +12,15 @@ SSL_set_session - Set an SSL session to be used during SSL connect
=head1 DESCRIPTION
SSL_set_session() sets B<session> to be used, when the SSL connection
is to be established. SSL_set_session() is only useful for SSL clients.
SSL_set_session() sets B<session> to be used when the TLS/SSL connection
is to be established. SSL_set_session() is only useful for TLS/SSL clients.
When the session is set, the reference count of B<session> is incremented
by 1. If the session is not reused, the reference count is decremented
again during SSL_connect().
If there is already a session set inside B<ssl> (because it was set with
SSL_set_session() before or because the same B<ssl> was already used for
a connection) SSL_SESSION_free() will be called for that session.
a connection), SSL_SESSION_free() will be called for that session.
=head1 RETURN VALUES
@ -30,7 +30,7 @@ The following return values can occur:
=item 0
The operation failed, check the error stack to find out the reason.
The operation failed; check the error stack to find out the reason.
=item 1

22
doc/ssl/SSL_shutdown.pod
View File

@ -2,7 +2,7 @@
=head1 NAME
SSL_shutdown - Shut down a TLS connection
SSL_shutdown - shut down a TLS/SSL connection
=head1 SYNOPSIS
@ -12,18 +12,18 @@ SSL_shutdown - Shut down a TLS connection
=head1 DESCRIPTION
SSL_shutdown() shuts down an active TLS connection. It sends the shutdown
alert to the peer. The behaviour of SSL_shutdown() depends on the underlying
SSL_shutdown() shuts down an active TLS/SSL connection. It sends the shutdown
alert to the peer. The behavior of SSL_shutdown() depends on the underlying
BIO.
If the underlying BIO is B<blocking>, SSL_shutdown() will only return, once the
handshake has been finished or an error occured.
If the underlying BIO is B<blocking>, SSL_shutdown() will only return once the
handshake has been finished or an error occurred.
If the underlying BIO is B<non-blocking>, SSL_shutdown() will also return,
If the underlying BIO is B<non-blocking>, SSL_shutdown() will also return
when the underlying BIO could not satisfy the needs of SSL_shutdown()
to continue the handshake. In this case a call to SSL_get_error() with the
return value of SSL_shutdown() will yield SSL_ERROR_WANT_READ or
SSL_ERROR_WANT_WRITE. The calling process then must repeat the call after
return value of SSL_shutdown() will yield B<SSL_ERROR_WANT_READ> or
B<SSL_ERROR_WANT_WRITE>. The calling process then must repeat the call after
taking appropriate action to satisfy the needs of SSL_shutdown().
The action depends on the underlying BIO. When using a non-blocking socket,
nothing is to be done, but select() can be used to check for the required
@ -42,13 +42,13 @@ The shutdown was successfully completed.
=item 0
The shutdown was not successfull. Call SSL_get_error() with the return
The shutdown was not successful. Call SSL_get_error() with the return
value B<ret> to find out the reason.
=item -1
The shutdown was not successfull, because a fatal error occured either
at the protocol level or a connection failure occured. It can also occure of
The shutdown was not successful because a fatal error occurred either
at the protocol level or a connection failure occurred. It can also occur of
action is need to continue the operation for non-blocking BIOs.
Call SSL_get_error() with the return value B<ret> to find out the reason.

24
doc/ssl/SSL_write.pod
View File

@ -2,7 +2,7 @@
=head1 NAME
SSL_read - Write bytes to a TLS connection.
SSL_read - write bytes to a TLS/SSL connection.
=head1 SYNOPSIS
@ -13,20 +13,20 @@ SSL_read - Write bytes to a TLS connection.
=head1 DESCRIPTION
SSL_write() writes B<num> bytes from the buffer B<buf> into the specified
B<ssl>. If necessary, SSL_write() will negotiate a TLS session, if
not already explicitely performed by SSL_connect() or SSL_accept(). If the
B<ssl>. If necessary, SSL_write() will negotiate a TLS/SSL session, if
not already explicitly performed by SSL_connect() or SSL_accept(). If the
peer requests a re-negotiation, it will be performed transparently during
the SSL_write() operation. The behaviour of SSL_write() depends on the
the SSL_write() operation. The behavior of SSL_write() depends on the
underlying BIO.
If the underlying BIO is B<blocking>, SSL_write() will only return, once the
write operation has been finished or an error occured.
write operation has been finished or an error occurred.
If the underlying BIO is B<non-blocking>, SSL_write() will also return,
when the underlying BIO could not satisfy the needs of SSL_write()
to continue the operation. In this case a call to SSL_get_error() with the
return value of SSL_write() will yield SSL_ERROR_WANT_READ or
SSL_ERROR_WANT_WRITE. As at any time a re-negotiation is possible, a
return value of SSL_write() will yield B<SSL_ERROR_WANT_READ> or
B<SSL_ERROR_WANT_WRITE>. As at any time a re-negotiation is possible, a
call to SSL_write() can also cause write operations! The calling process
then must repeat the call after taking appropriate action to satisfy the
needs of SSL_write(). The action depends on the underlying BIO. When using a
@ -42,17 +42,17 @@ The following return values can occur:
=item E<gt>0
The write operation was successfull, the return value is the number of
bytes actually written to the TLS connection.
The write operation was successful, the return value is the number of
bytes actually written to the TLS/SSL connection.
=item 0
The write operation was not successfull. Call SSL_get_error() with the return
value B<ret> to find out, whether an error occured.
The write operation was not successful. Call SSL_get_error() with the return
value B<ret> to find out, whether an error occurred.
=item -1
The read operation was not successfull, because either an error occured
The read operation was not successful, because either an error occurred
or action must be taken by the calling process. Call SSL_get_error() with the
return value B<ret> to find out the reason.