Re: [patch] Turn on Server Cipher Preference
On Friday 15 May 2015, Kyle Thompson wrote: Very basic patch to turn on server cipher preference in libtls. This will allow us to always use our cipher preference over what the client thinks is best. Tested with httpd as the server and openssl as the client with two ciphers selected. Should we make this a configurable option (possibly on by default)? Thanks - this has been on my todo list for a while. I think it needs to be a configuration option so that it can be disabled (in possibly strange use cases), however it should be on by default. Index: lib/libtls/tls_server.c === RCS file: /cvs/src/lib/libtls/tls_server.c,v retrieving revision 1.7 diff -u -p -r1.7 tls_server.c --- lib/libtls/tls_server.c 31 Mar 2015 14:03:38 - 1.7 +++ lib/libtls/tls_server.c 15 May 2015 04:12:43 - @@ -81,6 +81,8 @@ tls_configure_server(struct tls *ctx) EC_KEY_free(ecdh_key); } + SSL_CTX_set_options(ctx-ssl_ctx, SSL_OP_CIPHER_SERVER_PREFERENCE); + /* * Set session ID context to a random value. We don't support * persistent caching of sessions so it is OK to set a temporary -- Action without study is fatal. Study without action is futile. -- Mary Ritter Beard
Re: /etc/daily /tmp purge mods; skip open files with fstat test
On 2015-05-14 Thu 11:24 AM |, Todd C. Miller wrote: On Thu, 14 May 2015 17:48:49 +0100, Stuart Henderson wrote: Even not allowing for TOCTOU problems I'd be wary of running fstat automatically. If it is only used to detect when a file is in use that we would otherwise delete it seems reasonable. It is always annoying when daily removes /tmp files that are actually in use just because of their date. In the diff, there's no /dev/null redirects. Any errors could be obvious. Maybe some adventurous men could experiment with it for a fortnight see how it goes. Cool, -- http://www.stuff.co.nz/travel/themes/adventure/68507731/swiss-daredevil-yves-jetman-rossy-soars-over-dubai
Documentation fix for cwmrc(5)
This is essentially the opposite of this fix by Holger Mikolon, which was never merged: http://marc.info/?l=openbsd-techm=127765978812199 cwmrc(5) autogroup takes the windowname and windowclass in the opposite order than specified in the man page. Fix the man page. Index: app/cwm/cwmrc.5 === RCS file: /cvs/xenocara/app/cwm/cwmrc.5,v retrieving revision 1.59 diff -u -p -r1.59 cwmrc.5 --- app/cwm/cwmrc.5 25 Aug 2014 12:49:19 - 1.59 +++ app/cwm/cwmrc.5 15 May 2015 07:08:45 - @@ -40,7 +40,7 @@ The following options are accepted: .Pp .Bl -tag -width Ds -compact .It Ic autogroup Ar group windowclass -.It Ic autogroup Ar group windowname,windowclass +.It Ic autogroup Ar group windowclass,windowname Automatically add new windows to .Ar group if their class property matches
Small bridge(4) fix
If we change the rcvif pointer of a packet we need to run if_input()
again otherwise we might skip the handlers on the new interface.
Ultimately it would be nice to only assign rcvif in if_input(), but
that's for another diff.
This fix one case I left out in my previous conversion, ok?
Index: net/if_bridge.c
===
RCS file: /cvs/src/sys/net/if_bridge.c,v
retrieving revision 1.238
diff -u -p -r1.238 if_bridge.c
--- net/if_bridge.c 15 May 2015 10:15:13 - 1.238
+++ net/if_bridge.c 15 May 2015 10:50:32 -
@@ -1478,12 +1478,9 @@ bridge_dispatch(struct bridge_iflist *if
m-m_pkthdr.rcvif = ifl-ifp;
m-m_pkthdr.ph_rtableid = ifl-ifp-if_rdomain;
- if (ifp-if_type == IFT_GIF) {
- m-m_flags |= M_PROTO1;
- ether_input_mbuf(ifl-ifp, m);
- m = NULL;
- }
- return (m);
+ m-m_flags |= M_PROTO1;
+ ether_input_mbuf(ifl-ifp, m);
+ return (NULL);
}
if (bcmp(ac-ac_enaddr, eh-ether_shost, ETHER_ADDR_LEN) == 0
#if NCARP 0
vlan+bridge fix
I have one setup with multiple interfaces in a bridge and on some of
these interfaces some vlan(4)s. But there's currently a bug that
prevent us to send (receive is fine) VLAN packets in such config.
Diff below fixes that.
The problem is that vlan_output() does not pass its parent interface
to ether_output(). That's a mis-design that should be fixed later.
The reason for not passing the parent interface is that we want to
tcpdump(8) packets on vlan interfaces and the easiest hack^Wsolution
was to add a bpf handler in vlan_start()*.
Since my vlans are not part of the bridge, the check below is never
true and my packets never go through the bridge. By moving this
check to if_output() we kill two birds with one diff. First of
all we fix this vlan bug and secondly we simplify ether_output()
which in turn will allow us to fix all pseudo-interface *output()
functions.
One of the goals of if_output() is to move all bpf handlers instead
of having them in multiple if_start(). Of course, this will also
help us removing the various #if PSEUDODRIVER from our stack...
Ok?
*: Note that for the exact same reason we cannot tcpdump output
packets on a carp(4) interface, this will be fixed at the same
time in upcoming diffs.
Index: net/if_ethersubr.c
===
RCS file: /cvs/src/sys/net/if_ethersubr.c,v
retrieving revision 1.198
diff -u -p -r1.198 if_ethersubr.c
--- net/if_ethersubr.c 15 May 2015 10:15:13 - 1.198
+++ net/if_ethersubr.c 15 May 2015 10:58:37 -
@@ -363,47 +363,6 @@ ether_output(struct ifnet *ifp0, struct
if (ether_addheader(m, ifp, etype, esrc, edst) == -1)
senderr(ENOBUFS);
-#if NBRIDGE 0
- /*
-* Interfaces that are bridgeports need special handling for output.
-*/
- if (ifp-if_bridgeport) {
- struct m_tag *mtag;
-
- /*
-* Check if this packet has already been sent out through
-* this bridgeport, in which case we simply send it out
-* without further bridge processing.
-*/
- for (mtag = m_tag_find(m, PACKET_TAG_BRIDGE, NULL); mtag;
- mtag = m_tag_find(m, PACKET_TAG_BRIDGE, mtag)) {
-#ifdef DEBUG
- /* Check that the information is there */
- if (mtag-m_tag_len != sizeof(caddr_t)) {
- error = EINVAL;
- goto bad;
- }
-#endif
- if (!memcmp(ifp-if_bridgeport, mtag + 1,
- sizeof(caddr_t)))
- break;
- }
- if (mtag == NULL) {
- /* Attach a tag so we can detect loops */
- mtag = m_tag_get(PACKET_TAG_BRIDGE, sizeof(caddr_t),
- M_NOWAIT);
- if (mtag == NULL) {
- error = ENOBUFS;
- goto bad;
- }
- memcpy(mtag + 1, ifp-if_bridgeport, sizeof(caddr_t));
- m_tag_prepend(m, mtag);
- error = bridge_output(ifp, m, NULL, NULL);
- return (error);
- }
- }
-#endif
-
len = m-m_pkthdr.len;
error = if_output(ifp, m);
Index: net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.331
diff -u -p -r1.331 if.c
--- net/if.c15 May 2015 10:15:13 - 1.331
+++ net/if.c15 May 2015 10:58:37 -
@@ -450,6 +450,40 @@ if_output(struct ifnet *ifp, struct mbuf
length = m-m_pkthdr.len;
mflags = m-m_flags;
+#if NBRIDGE 0
+ /*
+* Interfaces that are bridgeports need special handling for output.
+*/
+ if (ifp-if_bridgeport) {
+ struct m_tag *mtag;
+
+ /*
+* Check if this packet has already been sent out through
+* this bridgeport, in which case we simply send it out
+* without further bridge processing.
+*/
+ for (mtag = m_tag_find(m, PACKET_TAG_BRIDGE, NULL); mtag;
+ mtag = m_tag_find(m, PACKET_TAG_BRIDGE, mtag)) {
+ if (!memcmp(ifp-if_bridgeport, mtag + 1,
+ sizeof(caddr_t)))
+ break;
+ }
+ if (mtag == NULL) {
+ /* Attach a tag so we can detect loops */
+ mtag = m_tag_get(PACKET_TAG_BRIDGE, sizeof(caddr_t),
+ M_NOWAIT);
+ if (mtag == NULL) {
+ m_freem(m);
+ return (ENOBUFS);
+ }
+ memcpy(mtag + 1,
Re: vlan+bridge fix
Diff is applied. So far no problems.
Unfortunately I can’t test this fully - no vlans on my side.
//mxb
On 15 maj 2015, at 13:14, Martin Pieuchot m...@openbsd.org wrote:
I have one setup with multiple interfaces in a bridge and on some of
these interfaces some vlan(4)s. But there's currently a bug that
prevent us to send (receive is fine) VLAN packets in such config.
Diff below fixes that.
The problem is that vlan_output() does not pass its parent interface
to ether_output(). That's a mis-design that should be fixed later.
The reason for not passing the parent interface is that we want to
tcpdump(8) packets on vlan interfaces and the easiest hack^Wsolution
was to add a bpf handler in vlan_start()*.
Since my vlans are not part of the bridge, the check below is never
true and my packets never go through the bridge. By moving this
check to if_output() we kill two birds with one diff. First of
all we fix this vlan bug and secondly we simplify ether_output()
which in turn will allow us to fix all pseudo-interface *output()
functions.
One of the goals of if_output() is to move all bpf handlers instead
of having them in multiple if_start(). Of course, this will also
help us removing the various #if PSEUDODRIVER from our stack...
Ok?
*: Note that for the exact same reason we cannot tcpdump output
packets on a carp(4) interface, this will be fixed at the same
time in upcoming diffs.
Index: net/if_ethersubr.c
===
RCS file: /cvs/src/sys/net/if_ethersubr.c,v
retrieving revision 1.198
diff -u -p -r1.198 if_ethersubr.c
--- net/if_ethersubr.c15 May 2015 10:15:13 - 1.198
+++ net/if_ethersubr.c15 May 2015 10:58:37 -
@@ -363,47 +363,6 @@ ether_output(struct ifnet *ifp0, struct
if (ether_addheader(m, ifp, etype, esrc, edst) == -1)
senderr(ENOBUFS);
-#if NBRIDGE 0
- /*
- * Interfaces that are bridgeports need special handling for output.
- */
- if (ifp-if_bridgeport) {
- struct m_tag *mtag;
-
- /*
- * Check if this packet has already been sent out through
- * this bridgeport, in which case we simply send it out
- * without further bridge processing.
- */
- for (mtag = m_tag_find(m, PACKET_TAG_BRIDGE, NULL); mtag;
- mtag = m_tag_find(m, PACKET_TAG_BRIDGE, mtag)) {
-#ifdef DEBUG
- /* Check that the information is there */
- if (mtag-m_tag_len != sizeof(caddr_t)) {
- error = EINVAL;
- goto bad;
- }
-#endif
- if (!memcmp(ifp-if_bridgeport, mtag + 1,
- sizeof(caddr_t)))
- break;
- }
- if (mtag == NULL) {
- /* Attach a tag so we can detect loops */
- mtag = m_tag_get(PACKET_TAG_BRIDGE, sizeof(caddr_t),
- M_NOWAIT);
- if (mtag == NULL) {
- error = ENOBUFS;
- goto bad;
- }
- memcpy(mtag + 1, ifp-if_bridgeport, sizeof(caddr_t));
- m_tag_prepend(m, mtag);
- error = bridge_output(ifp, m, NULL, NULL);
- return (error);
- }
- }
-#endif
-
len = m-m_pkthdr.len;
error = if_output(ifp, m);
Index: net/if.c
===
RCS file: /cvs/src/sys/net/if.c,v
retrieving revision 1.331
diff -u -p -r1.331 if.c
--- net/if.c 15 May 2015 10:15:13 - 1.331
+++ net/if.c 15 May 2015 10:58:37 -
@@ -450,6 +450,40 @@ if_output(struct ifnet *ifp, struct mbuf
length = m-m_pkthdr.len;
mflags = m-m_flags;
+#if NBRIDGE 0
+ /*
+ * Interfaces that are bridgeports need special handling for output.
+ */
+ if (ifp-if_bridgeport) {
+ struct m_tag *mtag;
+
+ /*
+ * Check if this packet has already been sent out through
+ * this bridgeport, in which case we simply send it out
+ * without further bridge processing.
+ */
+ for (mtag = m_tag_find(m, PACKET_TAG_BRIDGE, NULL); mtag;
+ mtag = m_tag_find(m, PACKET_TAG_BRIDGE, mtag)) {
+ if (!memcmp(ifp-if_bridgeport, mtag + 1,
+ sizeof(caddr_t)))
+ break;
+ }
+ if (mtag == NULL) {
+ /* Attach a tag so we can detect loops */
+ mtag = m_tag_get(PACKET_TAG_BRIDGE, sizeof(caddr_t),
+ M_NOWAIT);
+ if (mtag == NULL) {
ospfd announces carp interface with physical link down
I have found a peculiar behaviour in ospfd when the physical link of the
parent carp interface is down. The carp interface net is then announced
with it's regular metric.
An example:
The cable of em2, parent of carp2 (192.168.254.0/23), is unplugged. Here
is what is announced, seen by another machine running bird:
router 192.168.200.4
distance 10
network 192.168.200.0/24 metric 10
stubnet 192.168.202.0/24 metric 65535
stubnet 192.168.254.0/23 metric 10
stubnet 195.58.98.144/28 metric 65535
stubnet 92.33.0.200/30 metric 65535
stubnet 192.168.253.0/24 metric 10
192.168.254.0/23 is announced with metric 10. All other interfaces in
the same carp group are announced with metric 65535 because the
link-down state of em2 has demoted the carp group, as it should.
This behaviour is cased by the test for the carp state down doesn't
check for link state unknown.
Here is a patch that prevents ospfd from announcing the interface when
the physical interface is down. One could also argue that it should
announce it with metric 65535, as in the carp backup state. But I feel
it is better to not announce it at all since the link down state
prevents us from becoming the master.
Index: ospfe.c
===
RCS file: /cvs/src/usr.sbin/ospfd/ospfe.c,v
retrieving revision 1.90
diff -u -p -r1.90 ospfe.c
--- ospfe.c 10 Feb 2015 05:24:48 - 1.90
+++ ospfe.c 15 May 2015 13:02:40 -
@@ -880,7 +880,8 @@ orig_rtr_lsa(struct area *area)
if (!(iface-flags IFF_UP) ||
(!LINK_STATE_IS_UP(iface-linkstate)
!(iface-media_type == IFT_CARP
- iface-linkstate == LINK_STATE_DOWN)))
+ iface-linkstate == LINK_STATE_DOWN)) ||
+ (iface-media_type == IFT_CARP iface-linkstate
== LINK_STATE_UNKNOWN))
continue;
log_debug(orig_rtr_lsa: stub net,
interface %s, iface-name);
However, this if statement is difficult to understand as it is and
should probably be rewritten, maybe something like this:
Index: ospfe.c
===
RCS file: /cvs/src/usr.sbin/ospfd/ospfe.c,vretrieving revision 1.90
diff -u -p -r1.90 ospfe.c
--- ospfe.c 10 Feb 2015 05:24:48 - 1.90
+++ ospfe.c 15 May 2015 15:13:38 -
@@ -877,11 +877,17 @@ orig_rtr_lsa(struct area *area)
*backup carp interfaces have linkstate down, but
*we still announce them.
*/
- if (!(iface-flags IFF_UP) ||
- (!LINK_STATE_IS_UP(iface-linkstate)
- !(iface-media_type == IFT_CARP
- iface-linkstate == LINK_STATE_DOWN)))
- continue;
+ if (!(iface-flags IFF_UP))
+ continue; /* admin down */
+
+ if (iface-media_type == IFT_CARP) {
+ if (iface-linkstate LINK_STATE_DOWN)
+ continue; /* physical link down on carp if or
invaild */
+ } else {
+ if (!LINK_STATE_IS_UP(iface-linkstate))
+ continue; /* UP or UNKNOWN */
+ }
+
log_debug(orig_rtr_lsa: stub net,
interface %s, iface-name);
Also, is the carp kernel code really correct when it leaves the
interface link state as unknown when in carp init state?
/Johan Ymerson
Re: Small bridge(4) fix
No regression on my side.
//mxb
On 15 maj 2015, at 12:54, Martin Pieuchot m...@openbsd.org wrote:
If we change the rcvif pointer of a packet we need to run if_input()
again otherwise we might skip the handlers on the new interface.
Ultimately it would be nice to only assign rcvif in if_input(), but
that's for another diff.
This fix one case I left out in my previous conversion, ok?
Index: net/if_bridge.c
===
RCS file: /cvs/src/sys/net/if_bridge.c,v
retrieving revision 1.238
diff -u -p -r1.238 if_bridge.c
--- net/if_bridge.c 15 May 2015 10:15:13 - 1.238
+++ net/if_bridge.c 15 May 2015 10:50:32 -
@@ -1478,12 +1478,9 @@ bridge_dispatch(struct bridge_iflist *if
m-m_pkthdr.rcvif = ifl-ifp;
m-m_pkthdr.ph_rtableid = ifl-ifp-if_rdomain;
- if (ifp-if_type == IFT_GIF) {
- m-m_flags |= M_PROTO1;
- ether_input_mbuf(ifl-ifp, m);
- m = NULL;
- }
- return (m);
+ m-m_flags |= M_PROTO1;
+ ether_input_mbuf(ifl-ifp, m);
+ return (NULL);
}
if (bcmp(ac-ac_enaddr, eh-ether_shost, ETHER_ADDR_LEN) == 0
#if NCARP 0
mg: remove some unused #defines from def.h
Hey tech@ -- Let's get rid of some more #defines that aren't being used. Someone should also look at the list of prototypes and make sure all are being used. I can do this eventually, but probably not for a few weeks in case someone else wants to beat me to it. OK? ~Brian Index: def.h === RCS file: /cvs/src/usr.bin/mg/def.h,v retrieving revision 1.145 diff -u -p -r1.145 def.h --- def.h 25 Mar 2015 20:53:31 - 1.145 +++ def.h 16 May 2015 01:35:52 - @@ -21,7 +21,6 @@ typedef int (*PF)(int, int);/* generall #define NBUFN NFILEN /* Length, buffer name. */ #define NLINE 256 /* Length, line. */ #define PBMODES 4 /* modes per buffer */ -#define NKBDM 256 /* Length, keyboard macro. */ #define NPAT 80 /* Length, pattern. */ #define HUGE 1000/* A rather large number.*/ #define NSRCH 128 /* Undoable search commands. */ @@ -59,13 +58,6 @@ typedef int (*PF)(int, int);/* generall #define FIOERR 3 /* Error.*/ #define FIOLONG 4 /* long line partially read */ #define FIODIR 5 /* File is a directory */ - -/* - * Directory I/O. - */ -#define DIOSUC 0 /* Success. */ -#define DIOEOF 1 /* End of file. */ -#define DIOERR 2 /* Error.*/ /* * Display colors.
Re: UPD regression with
On May 13, 2015 3:37:39 AM GMT+02:00, David Higgs hig...@gmail.com wrote:
On May 11, 2015, at 9:02 PM, David Higgs hig...@gmail.com wrote:
On May 11, 2015, at 8:21 PM, David Higgs hig...@gmail.com
mailto:hig...@gmail.com wrote:
On Mon, May 11, 2015 at 8:07 PM, Alexander Hall alexan...@beard.se
mailto:alexan...@beard.sewrote:
Upgrading to the latest snapshot, I noticed my upd sensors had been
disturbingly crippled.
uhidev0 at uhub4 port 1 configuration 1 interface 0 EATON Eaton
3S rev 2.00/1.00 addr 2
uhidev0: iclass 3/0, 32 report ids
upd0 at uhidev0
Diff below is what happens from upd.c r1.13 to r1.14.
-hw.sensors.upd0.indicator0=On (ACPresent), OK
-hw.sensors.upd0.indicator1=On (Charging), OK
-hw.sensors.upd0.indicator2=Off (Discharging), OK
-hw.sensors.upd0.indicator3=Off (ShutdownImminent), OK
-hw.sensors.upd0.percent0=100.00% (FullChargeCapacity), OK
-hw.sensors.upd0.percent1=100.00% (RemainingCapacity), OK
+hw.sensors.upd0.indicator0=Off (ShutdownImminent), OK
+hw.sensors.upd0.indicator1=On (ACPresent), OK
Is this an expected fallout? Can I provide more info to assist? Full
dmesg (latest snap + vanilla current kernel w/ upd.c r1.13) follows.
It seems your device doesn't have a BatteryPresent report, or it is
somehow getting mangled. Can you run lsusb -v on your device and check
if Battery Present is shown?
If it is not, we'll have to make sensor dependencies less strict.
I'll start thinking about how to do this.
Alternatively, you could try the following diff, which flattens the
sensor dependency tree when a parent sensor isn’t available.
Below is a diff which has the correct number of parentheses and
actually compiles. Sorry for the noise.
Committed by mpi@. Thanks!
/Alexander
--david
--- a/upd.c
+++ b/upd.c
@@ -225,8 +225,12 @@ upd_attach_sensor_tree(struct upd_softc
for (i = 0; i nentries; i++) {
entry = entries + i;
- if (!upd_lookup_usage_entry(desc, size, entry, item))
+ if (!upd_lookup_usage_entry(desc, size, entry, item)) {
+ /* dependency missing, add children to parent */
+ upd_attach_sensor_tree(sc, desc, size,
+ entry-nchildren, entry-children, queue);
continue;
+ }
DPRINTF((%s: found %s on repid=%d\n, DEVNAME(sc),
entry-usage_name, item.report_ID));
Re: PATCH: clarifying iked.conf man
On Mon, Apr 20, 2015 at 07:35:58PM +0059, Jason McIntyre wrote: On Wed, Apr 15, 2015 at 05:13:13PM +0200, Vincent Gross wrote: Hello, iked.conf's man page is a bit fuzzy on how local and peer ip defaults are set. This patch below attempts to fix that. Also, can you take a look at my previous nat-on-ipsec-on-iked patchset ? see http://marc.info/?l=openbsd-techm=142662971007779w=2 Cheers, Index: iked.conf.5 === RCS file: /cvs/src/sbin/iked/iked.conf.5,v retrieving revision 1.38 diff -u -p -r1.38 iked.conf.5 --- iked.conf.5 28 Feb 2015 21:51:57 - 1.38 +++ iked.conf.5 15 Apr 2015 15:02:21 - @@ -334,23 +334,21 @@ see the file .It Ic local Ar localip Ic peer Ar remote The .Ic local -parameter specifies the address or FQDN of the local endpoint. -Unless the gateway is multi-homed or uses address aliases, -this option is generally not needed. -.Pp -The +and .Ic peer -parameter specifies the address or FQDN of the remote endpoint. -For host-to-host connections where +parameters specify the address or FQDN of the local and remote +endpoints respectively. +If neither are specified, their default values are equal to +.Ar src +and .Ar dst -is identical to -.Ar remote , -this option is generally not needed as it will be set to -.Ar dst -automatically. -If it is not specified or if the keyword -.Ar any -is given, the default peer is used. +for +.Ar localip +and +.Ar remote +respectively. When only one is specified, the other +defaults to +.Ar any . .It Xo .Ic ikesa .Ic auth Ar algorithm if you can specify one and have the other default to any, i agree we'd want to document it. for the rest, the diff essentially removes the information about when these options might be useful and needed. i'm less sure about that. i'd appreciate some feedback from a developer that the content is correct. i'm less inclined to rearrange the page this way without good reason. also note for future man diffs to start new sentences on new lines. jmc sorry, but i cannot get any feedback on this. i'm dropping it. jmc
Re: [patch] Turn on Server Cipher Preference
Here is an updated diff with some configuration added.
Index: lib/libtls/tls.h
===
RCS file: /cvs/src/lib/libtls/tls.h,v
retrieving revision 1.12
diff -u -p -r1.12 tls.h
--- lib/libtls/tls.h31 Mar 2015 14:03:38 - 1.12
+++ lib/libtls/tls.h15 May 2015 18:34:43 -
@@ -66,6 +66,9 @@ void tls_config_insecure_noverifycert(st
void tls_config_insecure_noverifyname(struct tls_config *_config);
void tls_config_verify(struct tls_config *_config);
+void tls_config_prefer_server_ciphers(struct tls_config *_config);
+void tls_config_prefer_client_ciphers(struct tls_config *_config);
+
struct tls *tls_client(void);
struct tls *tls_server(void);
int tls_configure(struct tls *_ctx, struct tls_config *_config);
Index: lib/libtls/tls_config.c
===
RCS file: /cvs/src/lib/libtls/tls_config.c,v
retrieving revision 1.9
diff -u -p -r1.9 tls_config.c
--- lib/libtls/tls_config.c 22 Feb 2015 15:09:54 - 1.9
+++ lib/libtls/tls_config.c 15 May 2015 18:34:43 -
@@ -82,6 +82,8 @@ tls_config_new(void)
tls_config_verify(config);
+ tls_config_prefer_server_ciphers(config);
+
return (config);
err:
@@ -299,4 +301,16 @@ tls_config_verify(struct tls_config *con
{
config-verify_cert = 1;
config-verify_name = 1;
+}
+
+void
+tls_config_prefer_server_ciphers(struct tls_config *config)
+{
+ config-prefer_server = 1;
+}
+
+void
+tls_config_prefer_client_ciphers(struct tls_config *config)
+{
+ config-prefer_server = 0;
}
Index: lib/libtls/tls_internal.h
===
RCS file: /cvs/src/lib/libtls/tls_internal.h,v
retrieving revision 1.12
diff -u -p -r1.12 tls_internal.h
--- lib/libtls/tls_internal.h 31 Mar 2015 12:21:27 - 1.12
+++ lib/libtls/tls_internal.h 15 May 2015 18:34:43 -
@@ -46,6 +46,7 @@ struct tls_config {
int verify_cert;
int verify_depth;
int verify_name;
+ int prefer_server;
};
#define TLS_CLIENT (1 0)
Index: lib/libtls/tls_server.c
===
RCS file: /cvs/src/lib/libtls/tls_server.c,v
retrieving revision 1.7
diff -u -p -r1.7 tls_server.c
--- lib/libtls/tls_server.c 31 Mar 2015 14:03:38 - 1.7
+++ lib/libtls/tls_server.c 15 May 2015 18:34:43 -
@@ -81,6 +81,10 @@ tls_configure_server(struct tls *ctx)
EC_KEY_free(ecdh_key);
}
+ if (ctx-config-prefer_server == 1) {
+ SSL_CTX_set_options(ctx-ssl_ctx,
SSL_OP_CIPHER_SERVER_PREFERENCE);
+ }
+
/*
* Set session ID context to a random value. We don't support
* persistent caching of sessions so it is OK to set a temporary
Re: TLS_READ_AGAIN and TLS_WRITE_AGAIN
On Sat, Apr 18, 2015 at 04:28:17PM +0800, Nathanael Rensen wrote: The tls_init(3) man page states: The tls_close(), tls_read() and tls_write() functions, along with the tls_accept() and tls_connect() function families, have two special return values: TLS_READ_AGAIN A read operation is necessary to continue. TLS_WRITE_AGAIN A write operation is necessary to continue. The caller should call the appropriate function or, in the case of the tls_close() and the tls_accept() and tls_connect() function families, repeat the call. I find the reference to appropriate function unclear. Perhaps there is some deeper meaning that I'm missing, but since in each case the required action is to repeat the call it is clearer to state that directly. I've also included a note about the non-blocking case. i'm sorry, but i've failed to drum up much (any, to be honest) interest in this. no one has replied publically either. so i'm dropping this from my list. having said that, the text seems perfectly clear to me. so i don;t really see any problem. jmc Index: tls_init.3 === RCS file: /cvs/src/lib/libtls/tls_init.3,v retrieving revision 1.23 diff -u -p -r1.23 tls_init.3 --- tls_init.33 Apr 2015 22:33:43 - 1.23 +++ tls_init.318 Apr 2015 07:38:38 - @@ -424,13 +424,14 @@ A read operation is necessary to continu A write operation is necessary to continue. .El .Pp -The caller should call the appropriate function or, in the case of the -.Fn tls_close -and the -.Fn tls_accept -and -.Fn tls_connect -function families, repeat the call. +In response to these return values the original call must be repeated +with the same arguments. +If the underlying socket is non-blocking the caller should first +confirm that the socket is ready to support the required operation, +such as by using +.Xr poll 2 +or +.Xr select 2 . .Sh ERRORS The .Fn tls_error
Re: [PATCH] relayd.conf man page confusion
On Mon, May 04, 2015 at 08:24:44PM -0400, trondd wrote: Fix a contradiction in the relayd.conf man page in the Protocols, tls section. The definition of TLS client and server is the opposite of what is stated in the forward and listen on descriptions, and the TLS Relays section. Tim. fixed, thanks. jmc Index: relayd.conf.5 === RCS file: /cvs/src/usr.sbin/relayd/relayd.conf.5,v retrieving revision 1.161 diff -u -p -r1.161 relayd.conf.5 --- relayd.conf.5 9 Mar 2015 17:20:38 - 1.161 +++ relayd.conf.5 5 May 2015 00:21:24 - @@ -905,12 +905,12 @@ are true: .Pp .Bl -bullet -compact -offset indent .It -TLS client mode is enabled by the +TLS server mode is enabled by the .Ic listen directive: .Ic listen on ... tls . .It -TLS server mode and divert lookups are enabled by the +TLS client mode and divert lookups are enabled by the .Ic forward directive: .Ic forward with tls to destination .
