RECENT BLOG NEWS
yaSSL Embedded Web Server – Alias Support
The yaSSL Open Source Embedded Web Server supports directory aliases. Similar to Apache’s mod_alias, using aliases allows a mapping to be created between URLs and file system paths. This mapping allows content which is not under the web server Document Root to be served as part of the web document tree. In other words, URLs beginning with the url-path will be mapped to local files beginning with the directory-path.
In the yaSSL Embedded Web Server, this can be done two ways:
1) Aliases can be set at runtime by using the -aliases option
2) Aliases can be set in the config file
In the following examples, suppose we wanted to map our local video directory (/home/user/Videos) to the URL “/videos”, and we wanted to map our pictures directory (/home/user/Pictures) to the URL “/pictures”.
Using the first option (setting the aliases at runtime), would look similar to the following.
./yasslEWS -aliases /videos=/home/user/Videos,/pictures=/home/user/Pictures
Using the second option (setting the aliases through the config file), we would need to add a line to our config file, as follows:
aliases /videos=/home/user/Videos,/pictures=/home/user/Pictures
To test if the newly set-up aliases are working correctly, point your web browser to one of the two URLs, where you should see a directory listing of the local files.
http://
http://
If this doesn’t work, double check that your paths are correct in your alias definitions and that everything is spelled correctly. Aliases should be able to be created for any drive physically attached to your computer.
To download the yaSSL Embedded Web Server, or to learn more, check out http://www.yassl.com. If you have any questions, contact us at info@yassl.com.
yaSSL Embedded Web Server – ACL Support
The yaSSL Open Source Embedded Web Server supports Access Control Lists. An Access Control List (ACL) allows restrictions to be put on the list of IP addresses which have access to the web server. In the case of the yaSSL Embedded Web Server, the ACL is a comma separated list of IP subnets, where each subnet is prepended by either a ‘-’ or a ‘+’ sign. A plus sign means allow, where a minus sign means deny. If a subnet mask is omitted, such as “-1.2.3.4”, this means to deny only that single IP address.
Subnet masks may vary from 0 to 32, inclusive. The default setting is to allow all, and on each request the full list is traversed – where the last match wins.
The ACL can be specified either at runtime, using the -acl option, or by using “acl” in the config file. For example, to allow only the 192.168.0.0/16 subnet to connect, you would run the following command:
./yasslEWS -acl -0.0.0.0/0,+192.168.0.0/16
The ACL can also be set in the web server config file. Using the example above, the config file line would be:
# acl -0.0.0.0/0,+192.168.0.0/16
To learn more about subnet masks, see the Wikipedia page on Subnetwork (http://en.wikipedia.org/wiki/Subnetwork), or here (http://wiki.xtronics.com/index.php/IP_Subnet_Masks).
To download the yaSSL Embedded Web Server, or to learn more, check out http://www.yassl.com. If you have any questions, contact us at info@yassl.com.
yaSSL Embedded Web Server – SSI Support
One of the features of the yaSSL Embedded Web Server is support for Server Side Includes. Server Side Includes (SSI) is a simple interpreted server-side scripting language which is most commonly used to include the contents of a file into a web page. It can be useful when it is desirable to include a common piece of code throughout a website.
Some of the ways in which Sever Side Includes may be used include:
– Including the contents of a file (html, txt, etc) into a web page
– Include the result of running a CGI script
– Executing a program, script, or shell command on the server
– Displaying the contents of a HTTP environment variable
– Outputting a list of variables and their values (environment and user-defined)
For more information on Server Side Includes, take a look at the Wikipedia entry here: http://en.wikipedia.org/wiki/Server_Side_Includes, or a tutorial on Server Side Includes can be found here: http://http-server.carleton.ca/~dmcfet/html/ssi.html.
To download the yaSSL Embedded Web Server, or to learn more, check out http://www.yassl.com. If you have any questions, contact us at info@yassl.com.
Open Source Embedded Web Server
Hi!
Have you checked out the yaSSL Embedded Web Server? With SSL enabled, it is sized small enough to fit into resource constrained environments at under 200k in footprint. However, it still has a useful feature set, including all of the standard web server functionality you would expect, plus features like support for CGI with your favorite language, including PHP, Perl, Python, Ruby on Rails, etc. Check it out at www.yassl.com.
Embedded SSL in the Holiday Spirit
Team yaSSL is preparing for Halloween here in the United States with a pumpkin carving! Our embedded security products are continually evolving. We encourage you to check our our wolfSSL embedded SSL library here, or our new yaSSL Embedded Web Server, here.
As always if you have any questions, or would like more information about our products, please contact us at info@yassl.com.
Thanks,
Team yaSSL
Great Article on Smart Meters in EE Times
See https://www.embedded.com/design/power-optimization/4209515/Robust-design-principles-for-home-smart-grid-metering for a great discussion on smart grid metering. There’s already wolfSSL users employing our embedded ssl to secure metering systems! wolfSSL is useful in smart grid metering for the following areas:
1. Delivering secure firmware updates to the metering device.
2. Encrypting data between the metering device and the main data store.
3. Encrypting data on the device.
Are you building smart grid devices? Let us know if we can help you with security concerns by contacting us at info@yassl.com.
Differences between SSL and TLS Protocol Versions
Have you heard talk about SSL 3.0, TLS 1.0, TLS 1.1, TLS 1.2, and TLS 1.3 but never really knew the differences between the different versions? Secure Socket Layer (SSL) and Transport Security Layer (TLS) are both cryptographic protocols which provide secure communication over networks. These different versions are all in widespread use today in applications such as web browsing, e-mail, instant messaging and VoIP, and each is slightly different from the others.
wolfSSL’s embedded SSL/TLS library supports all of these protocols to best suit your needs and requirements. Below you will find lists comparing each version of the SSL/TLS protocols, detailing major changes and updates from version to version.
SSL 3.0
This protocol was released in 1996, but first began with the creation of SSL 1.0 developed by Netscape. Version 1.0 wasn`t released, and version 2.0 had a number of security flaws, thus leading to the release of SSL 3.0. Some major improvements of SSL 3.0 over SSL 2.0 are:
- Separation of the transport of data from the message layer
- Use of a full 128 bits of keying material even when using the Export cipher
- Ability of the client and server to send chains of certificates, thus allowing organizations to use certificate hierarchy which is more than two certificates deep.
- Implementing a generalized key exchange protocol, allowing Diffie-Hellman and Fortezza key exchanges as well as non-RSA certificates.
- Allowing for record compression and decompression
- Ability to fall back to SSL 2.0 when a 2.0 client is encountered
TLS 1.0
This protocol was first defined in RFC 2246 in January of 1999. This was an upgrade from SSL 3.0 and the differences were not dramatic, but they are significant enough that SSL 3.0 and TLS 1.0 don`t interoperate. Some of the major differences between SSL 3.0 and TLS 1.0 are:
- Key derivation functions are different
- MACs are different – SSL 3.0 uses a modification of an early HMAC while TLS 1.0 uses HMAC.
- The Finished messages are different
- TLS has more alerts
- TLS requires DSS/DH support
TLS 1.1
This protocol was defined in RFC 4346 in April of 2006, and is an update to TLS 1.0. The major changes are:
- The Implicit Initialization Vector (IV) is replaced with an explicit IV to protect against Cipher block chaining (CBC) attacks.
- Handling of padded errors is changed to use the bad_record_mac alert rather than the decryption_failed alert to protect against CBC attacks.
- IANA registries are defined for protocol parameters
- Premature closes no longer cause a session to be non-resumable.
TLS 1.2
This protocol was defined in RFC 5246 in August of 2008. Based on TLS 1.1, TLS 1.2 contains improved flexibility. The major differences include:
- The MD5/SHA-1 combination in the pseudorandom function (PRF) was replaced with cipher-suite-specified PRFs.
- The MD5/SHA-1 combination in the digitally-signed element was replaced with a single hash. Signed elements include a field explicitly specifying the hash algorithm used.
- There was substantial cleanup to the client`s and server`s ability to specify which hash and signature algorithms they will accept.
- Addition of support for authenticated encryption with additional data modes.
- TLS Extensions definition and AES Cipher Suites were merged in.
- Tighter checking of EncryptedPreMasterSecret version numbers.
- Many of the requirements were tightened
- Verify_data length depends on the cipher suite
- Description of Bleichenbacher/Dlima attack defenses cleaned up.
TLS 1.3
This protocol is currently being revised, and is in its 28th draft. The major differences from TLS 1.2 include:
- The list of supported symmetric algorithms has been pruned of all legacy algorithms. The remaining algorithms all use Authenticated Encryption with Associated Data (AEAD) algorithms.
- A zero-RTT (0-RTT) mode was added, saving a round-trip at connection setup for some application data at the cost of certain security properties.
- Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.
- All handshake messages after the ServerHello are now encrypted.
- Key derivation functions have been re-designed, with the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) being used as a primitive.
- The handshake state machine has been restructured to be more consistent and remove superfluous messages.
- ECC is now in the base spec and includes new signature algorithms. Point format negotiation has been removed in favor of single point format for each curve.
- Compression, custom DHE groups, and DSA have been removed, RSA padding now uses PSS.
- TLS 1.2 version negotiation verification mechanism was deprecated in favor of a version list in an extension.
- Session resumption with and without server-side state and the PSK-based ciphersuites of earlier versions of TLS have been replaced by a single new PSK exchange.
Resources:
If you would like to read more about SSL or TLS, here are several resources that might be helpful:
TLS Wikipedia article: http://en.wikipedia.org/wiki/Transport_Layer_Security
TLS 1.3 overview: https://www.wolfssl.com/docs/tls13/
As always, if you have any questions or would like to talk to the wolfSSL team about more information, please contact facts@wolfssl.com.
wolfSSL Supports the RIM PlayBook
Did you know that wolfSSL supports running on the RIM PlayBook? The PlayBook runs the QNX operating system, which we have supported for the last five years – ever since our first source release of wolfSSL.
We have posted before about wolfSSL`s build sizes on QNX, which are an impressive 80k (compared to a standard OpenSSL build of 2M). With QNX`s successful track record, we are proud to support the RIM PlayBook.
If you plan on trying out wolfSSL on the PlayBook, let us know! In addition, if you need any help with wolfSSL and QNX, we`d be more than happy to help out! For more information on wolfSSL`s feature list, please see the wolfSSL product page.
View the PlayBook product page: http://na.blackberry.com/
Learn more about QNX from their website: http://www.qnx.com/
If you have any questions or want more information, please contact info@yassl.com.
EE Times reports on VDC Research survey of Embedded Software
See Jack Ganssle’s discussion on the report here: https://www.embedded.com/electronics-blogs/break-points/4208881/2010-VDC-survey-of-embedded-software. A couple items stand out for us, as a company providing open source embedded ssl:
1. 46% of embedded developers are using a TCP/IP stack. What we’d like to know is the subset of those developers using SSL. If embedded ssl usage maps to general ssl usage studies, it would be about 1-2%. That means a whole lot of devices in a whole lot of places are subject to man in the middle attacks, and worse.
1. The survey also tells us that about 20% of the developers are using open source in some fashion, but it does not tell us why they chose open source. In any event, 20% is a good start! We’d like to pull out our soap box and lecture on why open source produces higher quality software faster than legacy proprietary approaches, but that argument is well documented elsewhere.
Feedback on the wolfSSL Java SSL Provider for Android
Hi!
Our Java-based SSL provider has been in alpha for two months now, and we’re actively preparing a beta release. Please contact us at info@yassl.com if you have identified bugs, want to request a feature, or think you’ve spotted potential optimizations.
Thanks!
Team yaSSL
Weekly updates
Archives
- April 2025 (24)
- March 2025 (22)
- February 2025 (21)
- January 2025 (23)
- December 2024 (22)
- November 2024 (29)
- October 2024 (18)
- September 2024 (21)
- August 2024 (24)
- July 2024 (27)
- June 2024 (22)
- May 2024 (28)
- April 2024 (29)
- March 2024 (21)
- February 2024 (18)
- January 2024 (21)
- December 2023 (20)
- November 2023 (20)
- October 2023 (23)
- September 2023 (17)
- August 2023 (25)
- July 2023 (39)
- June 2023 (13)
- May 2023 (11)
- April 2023 (6)
- March 2023 (23)
- February 2023 (7)
- January 2023 (7)
- December 2022 (15)
- November 2022 (11)
- October 2022 (8)
- September 2022 (7)
- August 2022 (12)
- July 2022 (7)
- June 2022 (14)
- May 2022 (10)
- April 2022 (11)
- March 2022 (12)
- February 2022 (22)
- January 2022 (12)
- December 2021 (13)
- November 2021 (27)
- October 2021 (11)
- September 2021 (14)
- August 2021 (10)
- July 2021 (16)
- June 2021 (13)
- May 2021 (9)
- April 2021 (13)
- March 2021 (24)
- February 2021 (22)
- January 2021 (18)
- December 2020 (19)
- November 2020 (11)
- October 2020 (3)
- September 2020 (20)
- August 2020 (11)
- July 2020 (7)
- June 2020 (14)
- May 2020 (13)
- April 2020 (14)
- March 2020 (4)
- February 2020 (21)
- January 2020 (18)
- December 2019 (7)
- November 2019 (16)
- October 2019 (14)
- September 2019 (18)
- August 2019 (16)
- July 2019 (8)
- June 2019 (9)
- May 2019 (28)
- April 2019 (27)
- March 2019 (15)
- February 2019 (10)
- January 2019 (16)
- December 2018 (24)
- November 2018 (9)
- October 2018 (15)
- September 2018 (15)
- August 2018 (5)
- July 2018 (15)
- June 2018 (29)
- May 2018 (12)
- April 2018 (6)
- March 2018 (18)
- February 2018 (6)
- January 2018 (11)
- December 2017 (5)
- November 2017 (12)
- October 2017 (5)
- September 2017 (7)
- August 2017 (6)
- July 2017 (11)
- June 2017 (7)
- May 2017 (9)
- April 2017 (5)
- March 2017 (6)
- January 2017 (8)
- December 2016 (2)
- November 2016 (1)
- October 2016 (15)
- September 2016 (6)
- August 2016 (5)
- July 2016 (4)
- June 2016 (9)
- May 2016 (4)
- April 2016 (4)
- March 2016 (4)
- February 2016 (9)
- January 2016 (6)
- December 2015 (4)
- November 2015 (6)
- October 2015 (5)
- September 2015 (5)
- August 2015 (8)
- July 2015 (7)
- June 2015 (9)
- May 2015 (1)
- April 2015 (4)
- March 2015 (12)
- January 2015 (4)
- December 2014 (6)
- November 2014 (3)
- October 2014 (1)
- September 2014 (11)
- August 2014 (5)
- July 2014 (9)
- June 2014 (10)
- May 2014 (5)
- April 2014 (9)
- February 2014 (3)
- January 2014 (5)
- December 2013 (7)
- November 2013 (4)
- October 2013 (7)
- September 2013 (3)
- August 2013 (9)
- July 2013 (7)
- June 2013 (4)
- May 2013 (7)
- April 2013 (4)
- March 2013 (2)
- February 2013 (3)
- January 2013 (8)
- December 2012 (12)
- November 2012 (5)
- October 2012 (7)
- September 2012 (3)
- August 2012 (6)
- July 2012 (4)
- June 2012 (3)
- May 2012 (4)
- April 2012 (6)
- March 2012 (2)
- February 2012 (5)
- January 2012 (7)
- December 2011 (5)
- November 2011 (7)
- October 2011 (5)
- September 2011 (6)
- August 2011 (5)
- July 2011 (2)
- June 2011 (7)
- May 2011 (11)
- April 2011 (4)
- March 2011 (12)
- February 2011 (7)
- January 2011 (11)
- December 2010 (17)
- November 2010 (12)
- October 2010 (11)
- September 2010 (9)
- August 2010 (20)
- July 2010 (12)
- June 2010 (7)
- May 2010 (1)
- January 2010 (2)
- November 2009 (2)
- October 2009 (1)
- September 2009 (1)
- May 2009 (1)
- February 2009 (1)
- January 2009 (1)
- December 2008 (1)